Erlang vs Go

This is a creation in Article, where the information may have evolved or changed.

1) Design

The implementation of Erlang is based on the virtual machine Beam,go is a compiled language, with a single compiler (unlike Gcc,go very good to solve the problem of dependency, so when compiling the GO program does not need to compile the C program as specified in the Include and library), TNSDL and go are similar, belonging to native execution. Erlang is primarily for carrier-grade applications, while Go's concurrent is more versatile, mainly in the design of concurrent, where Erlang transmits a message between process and go is a goroutine composition, Plus Channel,go by decoupling process and message to make the design of go more versatile and flexible, the application can decide whether to need channel processing according to its own demand. The routine plus channel design is also available in stackless python (some say go = C + stackless python), which is the flexibility of the channel so that go does not need to be returned in the Pid,go in Erlang, The spawn in Erlang returns the PID. Erlang does not control the message buf, and using the Go channel can control the Capacity,make of the channel (Chan int, 100)

2) Library

Erlang has a history of more than more than 20 years, and various behavior,driver support in OTP makes using Erlang handy. The history of Go is much shorter and the library is still lacking.

3) Scheduler

From an implementation perspective, each process in Erlang has its own heap, so it is not possible to share memory, in general the scheduler of Erlang is very similar to the Linux kernel, and go and SDL belong to native, which focuses on fairness, Each process in Erlang has a reduction, similar to the time slice,go of the process in Linux kernel is native execution, so how does go runtime control the fairness of each goroutine? The answer is no, the goroutine that native executes cannot guarantee fairness like Erlang, Goroutine can only have the opportunity to re-execute schedule functions in Syscall, IO, channel Read write operations. To perform the rest of the goroutine. In concurrent language, it is very important to solve the problem of fair scheduling and priority scheduling.

Given that go is not too mature, maybe there will be improvements later, scheduler and GC have a lot of discussion, now scheduler implementation logic and its simple (G & M), compared to the Erlang Scheduler is more simple (there are some bugs, but also the question of fairness).

Erlang Scheduler is located at: otp/erts/emulator/beam/erl_process.c

Go Scheduler located in: GO/SRC/PKG/RUNTIME/PROC.C

4) memory model

Each process in Erlang has its own heap,stack at the bottom of the heap, where the stack is a stack of Erlang process, similar to the operand stack in Java, stack down, stack top encountered heap top , the stack is moved to a new place after GC,GC.

Go is native execution, Goroutine stack is segment STACK,TNSDL runtime is also using this segment Stack,segment stack is a program that has a lot of stack execution, Stack switching is achieved through SETJMP,LONGJMP. (One of the main applications of setjmp and longjmp is concurrent, and the other is simulating try catch in C)

5) GC Garbage collection

Erlang's GC is a generational algorithm, with an old heap, with minor GC and full sweep, which is generally similar to Java, except that Erlang does not have the mark process and finds all eterm on the newly allocated heap directly according to Rootset.

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

6) High Reliability

Erlang has a builtin of high reliability, such as link and monitor mechanism.

Go is a universal design, although the link and monitor,goroutine without built-in can use defer to achieve the effect of link.

7) Performance

One of the real goals of Go is high performance, which is why go is a compiled language. Theoretically, the performance of Goroutine is better than Erlang's process, but performance in software design principles is only one of the metrics, not all.