Some ideas about go and Erlang

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

Some ideas about go and Erlang

Original link: http://blog.erlware.org/some-thoughts-on-go-and-erlang/
The following is my translation, only for the exchange of learning, copyright belongs to the original author, reproduced please indicate the source, please do not use for commercial purposes.

Update: I found that my article did not make the point clear. I'm not saying go can't or should be improved, because it's not the same as Erlang. I want to say that go is still not a replacement for Erlang in high-concurrency backend areas where availability and low latency are indispensable. It is important to note that I do not write this article about a particular language such as Julia. I've heard that go has become a replacement for Erlang, not just in new projects, but in old projects that replace new languages. No one says Julia is the same, but go and node. js are seen by some as a friendly alternative to Erlang. Erlang is not for all, and here I'll just discuss exactly where Erlang fits and where go doesn't fit.
I'm going to get rid of some of my subjective remarks about not being fond of go, such as grammar or lack of pattern matching, and explain the language itself and the objective reasons why it's not suitable for some systems to run.

Go's strengths

Client

As Rob Pike once said, his biggest surprise was that go attracted a lot of python and Ruby programmers to turn to it instead of C + +. For me, this trend is also very happy to see. Those slow clients that are installed with PIP or gems will no longer appear (although there are more and more reasons to do clients with node. JS, the keybase of the slot).
Go provides developers with a fast, easy-to-use, high-level, static-type language with garbage collection and concurrency primitives. Because of these advantages, C + + developers turn to go is easy, on my machine often crashes the program Hipchat and Spotify, is written in C + +, it is good at inappropriate use of memory. But Rob Pike points out that C + + developers don't want to use this simple and powerful go. Ruby and Python programmers, however, are willing to move on to go.

Tools

Not based on third-party tools, but based on third-party libraries, compiling executable processes can be easily done, which is the advantage of go. While this tool is not perfect, there are tools that can fill these shortcomings, such as GODEP, which is a huge step forward for the language.

The downside of Go

In writing low-latency fault-tolerant systems, some go designs are flawed.

Concurrent

Yes, in the additional part of the first part, I mentioned the Concurrency primitives, which is why many clients go instead of Ruby,python or C + +. But in complex back-end systems that require fault tolerance, go is not as shared as other languages.

preemption Scheduling

Go is much better in this regard. Go preemption is done through the system, but now in each function call, a goroutine check stack when the preemption schedule will also occur. If this goroutine is running for a long time, it may be marked as failed (causing a preemption schedule). Although this is an improvement, it still lags behind the count of Erlang and is later added to the dirty dispatch in order to improve C.

Garbage collection

The garbage collection in Go is globally marked and cleared. This pauses all goroutines during the purge phase, which is bad for low latency. Also, low latency is difficult, and the more you run it, the better you will say.

Error handling

This is not to discuss the use of an exception or exception check if the second return value is nil. Goroutine without an identity means that go lacks the ability to connect and monitor Goroutines. No connection (replaced by panic and defer) and no process isolation means that you cannot fall back and restart during a crash when you are in a stable state. This leads to a lot of bugs in the product, many of which are Heisenberg bugs, so it's possible to isolate processes from one another, but based on their dependencies, it's the key to fault tolerance.
In addition, on error handling go has nil, it was considered feasible in 2014, but I do not agree, but I do not care about this, first see.

Reflection

It is annoying to have no repl at the time of development, and no remote shell is a fatal injury to a running system. Erlang has an impressive tracing feature, as well as tools based on this feature such as Recon Trace. Erlang's self-introspection greatly improves development and also improves maintenance on complex systems.

Static connection

Yes, one thing is good but it becomes bad, like spending a lot of time running on a system. Although no connection can cause slow execution, it gives Erlang an advantage in code substitution on a running system. It is important that because of the scheduling and garbage collection strategies of Erlang, the tradeoff between the various speeds does not mean that Erlang is slower than other languages in the same application, especially if only Erlang is running.

Code Organization

The OTP framework provides a library for common mode. OTP can not only write programs with less and better abstract code, but also improve readability. With the OTP standard added to the application, superior and regular employees (Genserver, GENFSM, gen_event) mean that a new developer can work quickly and communicate with each other through the process tree. Go channels, unrecognized goroutines and lack of patterns to separate goroutines into different modules will cause the code to become more and more difficult to write.

Should go change, can it change?

Erlang has been around for decades, and go is a new kid, so can go improve in these areas? Maybe some can, but more is not possible, because the language itself lacks fault tolerance and low latency.
This is not to say that go is bad or wrong, and that it can make different, more appropriate choices for different problem handling than other Erlang-like languages.