Erlang vs go

1) Design

The implementation of Erlang is based on the virtual machine beam. Go is a compilation language and has a single-integrated Compiler (unlike GCC, go solves the dependency problem very well, therefore, when compiling the go program, you do not need to specify the include and Library as the C program.) tnsdl is similar to go and belongs to native execution. Erlang mainly serves telecom-level applications, while go concurrent is more universal. This is mainly reflected in the design of concurrent. Erlang transmits messages between processes, while go is composed of goroutine, in addition, with the channel, go decouples process and message to make the Go design more universal and flexible. The application can decide whether to process the channel based on its own needs. Routine and channel are designed in stackless
Python is also available (Some people say go = C + stackless Python). It is precisely because of the flexibility of the channel that the PID in Erlang is not required in go, And the go in go does not return values, the spawn in Erlang returns the PID. Erlang does not control the message Buf. Using the go channel, you can control the capacity, make (Chan int, 100) of the channel)

2) Library

Erlang has more than 20 years of history, and various behavior in OTP. The driver support makes it easy to use Erlang. The history of Go is much shorter, and library is still lacking.

3) Scheduler

From the implementation perspective, each process in Erlang has its own heap, So memory cannot be shared. In general, Erlang's scheduler is very similar to Linux kernel; go and SDL are native executions, here we mainly discuss the issue of fairness. in Erlang, each process has a function, which is similar to the time slice of the Process in Linux kernel. Go is the native execution, so how does the go runtime control the fairness of each goroutine? The answer is no. The goroutine executed by native cannot guarantee the fairness as Erlang does.
The read write operation can have the opportunity to re-execute the schedule function to execute other goroutine. In concurrent, fair scheduling and priority scheduling cannot be well solved.

Since go is not yet mature and may be improved in the future, scheduler and GC have a lot of discussions. The implementation logic of scheduler and Its simplicity (G & M ), compared with the Erlang scheduler, it is simpler (there are some bugs in it, and there are also issues with fairness ).

Erlang scheduler is located at: OTP/ERTs/emulator/beam/erl_process.c

Go scheduler is located at: Go/src/PKG/runtime/proc. c

4) Memory Model

In Erlang, each process has its own heap. the stack is at the bottom of the heap. The stack here is the stack of Erlang process, which is similar to the operand stack in Java. The stack grows down, in case of heap top, perform GC. After GC, move the stack to a new place.

Go is a native execution, goroutine's stack is a segment stack, and tnsdl's runtime also uses this segment stack. segment stack is a program that has many stacks for execution, and stack switching is performed through setjmp, longjmp implementation. (One of the main applications of setjmp and longjmp is concurrent, and the other is simulating try catch in C)

5) GC garbage collection

The GC of Erlang is a generational algorithm with an old heap, minor GC, and full sweep. In general, it is similar to Java, except that Erlang has no mark, locate all eTerms in the newly allocated heap based on the rootset.

Go is now Mark-sweep and will use IBM's low-latency GC algorithm in the future.

6) High Reliability

Erlang has a builtin high reliability, such as the link and monitor mechanisms.

Go is a universal design. Although there is no link and monitor for built-in, goroutine can use defer to implement the link effect.

7) Performance

One of the goals of Go is high performance, which is why go is a compilation language. Theoretically, the performance of goroutine is better than that of Erlang. However, in software design principles, performance is only one of the criteria, not all.