Not the struggle for language--go vs Erlang

Because of the high concurrency and low latency requirements of the system, we have done a lot of research and comparison work on various languages and platforms. This naturally includes Go and Erlang, which are dedicated to developing high-concurrency applications.

Concurrent

Go's support for high concurrency is achieved through goroutine. Goroutine can be understood as lightweight threads (thread). The Goroutine shared address space created by the same Go app.

The high concurrency of Erlang is achieved through lightweight processes (process), each of which has a separate state record.

Also, use Goroutine to be aware that after the Goroutine has finished running, the memory that is occupied is put back into the memory pool for backup and will not be freed.

Erlang's process is more advantageous in situations where each task requires a separate state.

Preemptive scheduling

The Task Scheduler for Erlang has a reduction budget concept. Any operations of the process can result in budget consumption, including function calls, call BIF, Process heap garbage collection, ETS read and write, and message (the more messages the target mailbox accumulates, the greater the consumption). The regular expression library for Erlang has also been modified to support reductions. So if a process performs regular expression matches over a long period of time, it will consume reductions and be preempted as well.

The scheduler before Go is dispatched only when syscall occurs, and can be dispatched when any function calls are optimized. Note, however, that if you write a dead loop in Goroutine, the Go Scheduler is not effectively preempted, and the other goroutine of the same scheduler will be suspended.

Garbage collection

Like Java, Go's garbage collection is global, which means that once garbage collection is triggered, all goroutine are paused, causing a period of business delay.

Erlang garbage collection is process-level, each process has its own separate garbage collector, and a process garbage collection is triggered without causing other processes to be suspended. Relatively small business delays.

Error handling

Each process in Erlang has a process ID (PID) and can also register a name for the process, which means that each process has a separate identity and can effectively monitor the status of each process. When the process exits abnormally, you can snap to the exit event and restart the process (see OTP Supervisor/worker).

Go goroutine No identification, goroutine state is not able to monitor.

Dynamic reflection

The features of Erlang dynamic language make it natural to support REPL, and Erlang supports remote shell, and we can connect to the remote shell to interact with any process while Erlang is running. These features greatly facilitate the maintenance of a complex system that requires long-term operation. The development phase can also have some convenience.

Go is a static language and does not support REPL.

Static compilation

Erlang is a dynamic language with all the drawbacks of all dynamic languages:

• Slow operating Speed
• Can not do early error checking, need to rely on full coverage unit test
• The code is big and confusing to write

Erlang now also introduces spec, which does a type check on the function's parameter return value at compile time, but it is far worse than the static language.

But precisely because it is a dynamic language, Erlang implements runtime code substitution, which is a very important feature for an industrial-grade product that needs to run for a long time.

Go is a static language, run fast, compile a strict type check, you can avoid a lot of hidden dangers.

Framework

Erlang's OTP framework supports several common patterns of server-side development (applications, supervisors, wokers), and facilitates the organization of code.

Go does not see a similar frame for the moment.

Third-party library support

Go is a relatively new language, although many projects now start to support Go, but many third-party libraries are less mature than Erlang for the time being.

Summarize

For back-end services that require low latency and high concurrency, we have recently adopted Erlang as the dominant feature. But in the process of using Erlang, Erlang lacks the means of static checking and is also a troublesome problem, and the current practice is to require everyone to write code using IntelliJ idea, which can be discovered in advance by the IDE in some language issues.

At the same time we will continue to focus on the development of Go.

About the author

Tiger

Weibo: @Tiger_ Zhang Hu, founder of Inyumba (Yunba.io), Yunba.io Cloud backend services. Jpush founder, former CTO. A member of the Oracle VM founding team.

Not the struggle for language--go vs Erlang