[ZZ] A few superficial comparisons of Erlang and Golang

This is a creation in Article, where the information may have evolved or changed. Saturday should be Hoterran invited, let me spit out the slot for Erlang and go, so while in Sunday, casually sprayed a few words, first do a Golang advertisement: Golang Online QQ Group: 259718627
The first language I used was Java and Python, and I always had a crush on Python, and I liked the feeling of simplicity and efficiency, but I didn't use Python in the end, because it was simple, I just didn't like the indentation syntax, Just for a lot of people to change jobs just for the screen larger, and also have the same great option, this is Ruby, so I finally adopted Ruby as the main programming language, but also for the inability to use Python a little bit of a pity, after all, Python's robustness is much better than Ruby, It's just that Ruby has been making progress, so it's harmless.
We all know that whether it is Python or ruby, or even Java, is to solve the business layer of the problem, belongs to the application-oriented language to solve business logic, but there is a domain is the system domain, the network layer and the underlying operation, in this piece I have been looking for an elegant solution, C + + By my first to eliminate, c development efficiency is too low, Java is more appropriate, is too bloated, and lack of system programming genes, after all, it is enterprise-level development background
Finally I chose Erlang, because it performs well in the network layer, while the fault-tolerant and robustness are very good, its virtual machine is the only one comparable to the JVM, but also the OTP super-heavyweight weapons, almost can be a network layer application, but according to my summary it has a mishap and a soft rib, This point behind the expansion, it can be said that the choice of Erlang is what I now know the solution is the best
Until one day I understand Golang, I know Golang is actually very early, about 08 years when the Google in a strange language, after a few years, has been a lot of people in the old Mo as the representative of the person in the muttering Golang, in fact, I have not been too concerned about, I learned from the ROR experience is , maturity for the business is very important, and later based on the development of Golang products more and more, let me have to study, this I know, this is my dream of Python, the efficiency and performance to achieve the best balance, the more go know more, the less willing to write code in Erlang, the main reason:
1, Erlang's mishap is the readability of the code, expressive, let me give a small example, such as you build a restful interface for your system software, we have a general understanding of the code style, with erlang:https://github.com/extend/ Cowboy/tree/master/examples with go:http://code.google.com/p/goweb/wiki/getstarted, don't say Erlang, either you c/c++/python/ruby/ Java origin, to go is not a very long-lost feeling, why is the mishap? Because of a language, grammar is not likely to be significantly changed, and there will be no big changes, I do not know if anyone has read the "as Programming World", the rationale is very clear, the real good programming is the person to dominate the computer rather than the computer dominate people, I feel that Erlang is a bit of a master of my sense of programming thinking (my eyesight is not good, it's still killing my eyes!) ), programming first is the door logic, followed by engineering, and finally mathematics, but also reminds me of Wu, "The Beauty of Mathematics," said, artificial intelligence in the past century has been detours, the expectation of the height of the machine Turing complete, and ignore the human own civilization, statistical induction of the application
2, Erlang's soft rib lies in the high-quality library less, although there are many killer applications, the same go in this area is also a soft rib, this point for a less than five years of language can be original, but for a more than 20-year language is not a bit justified, such as you use JSON parsing library, A lot of people are from mochiweb this basically does not update the library to extract, and I think for JSON-like such things can be considered into the language standard library, because the future of the commercial software API trend is more and more obvious, said the ugly point, a imposes with the times, Anyway, I am not worried about Golang's library, I am very good at present, I am far better than the first five years of Ruby/python, see the list of high quality libraries available http://go-lang.cat-v.org/pure-go-libs
3, Erlang is not gregarious, this is mainly reflected in the interaction with other languages, of course, this also has a deep-seated reason, Erlang itself has its own philosophy, such as error recovery mechanism, you into a other language things into, this account is not good, like you hard to let a drink coffee with a eat garlic sitting together , anyway you write a Erlang port far more complex than go, even more complicated than Python/java, which makes Erlang not very good at the bottom of the programming, can not take advantage of many of the good results of Linux, I always think of what Erlang's mysql/ Pg/oracle drive is not necessary to exist, Erlang must be a self-container application, you just use the other things, according to the Cask theory, you do not dare to claim 9 9, with a systematic view of the problem, I think a system of robustness can not rely on a component, This is why Ericsson's own Erlang applications are not widely
4, say the data type, I hear more than 1 people say that Erlang does not handle string processing, it is a list to deal with string, in fact, it is so, but, or that sentence, contrary to human-oriented philosophy, should do some DSL, such as golang inside: = is a icing , equivalent to var xx yyy = zzzz, greatly convenient programmer to knock a lot of characters, Golang inside on the character can be said basic and Python almost, slice map function is very powerful, support lambda condition, although the basic type of Erlang is very few, but there are many constructs, The so-called structure is equivalent to the golang inside the complex struct, also strange, I just feel the Erlang structure injured eyes good? May be the reason for the various brackets, and I think it is unnecessary, obviously Erlang lacks the gene of DSL, of course, with the age of Erlang, I do not exaggerate that, since the use of Erlang, my eyesight has dropped by about 100 degrees, I don't really like Lisp. The notation is also a kind of grammar, perhaps this is related to functional programming: Formal derivation is much more than logical deduction
5, in fact, my least concern is the performance problem, because with Moore's Law, Unit calculated unit cost will be infinitely high, but Golang since proposed its performance approximation C, then I still mention it, of course, Erlang also can, although slower than Java, but with Python a grade bar
6, then talk about the error mechanism, because Erlang's error message is too tangled, at first thought I would not see error messages, and later also used SASL, or not enough intuitive, and sometimes to use tools to analyze crash files to locate the problem, or with the philosophy of Erlang, In Erlang everything is parallel, so it is not care is the physical which line of error, only with the actor binding, and then tell you actor ID and error code, you own experience to analyze it, the advantage is that it can be very convenient to locate the problem in parallel, but everything is relative, In this point is a bit wrong, according to my experience, most of the time I just want to give me a clear point of which line of error, okay? Even the order of the BackTrace with the complete English sentence to print it? As for the errors in parallel in a timely manner in the command-style multithreaded language is not common, although not without, but encountered errors I try to debug, but not all the logic to use parallel thinking to locate the problem, I even think, for a system is not entirely parallel is not completely serial, As we measure the world can not be pure materialism can not be completely idealistic, this point golang do a good compromise, do not need parallel when you honestly write serial code, need to parallel time also have more complex mechanism to deal with, reasonable
7, say again recruit bar, before a few c out of people, to tell the truth level is very good, can complete a week on a small component, libevent with the cooked very, later I pressed the home Erlang, the result of someone forced to go, so far I still regret, their wishful thinking is too inappropriate to impose on others, But I recruit pure erlang out of people, can say than recruit objc people still difficult, no one, talk about the elegance of technology first is not reliable, and then look at the mailing list, Golang activity is significantly higher than Erlang, see the weekend Golang discussion HTTP/ www.douban.com/photos/photo/1683652416/, the basic approximation of Ruby, more importantly, I do not worry about Golang talent, because as long as familiar with python/c/ruby/or C + +, basic can achieve half a day to get started, After that can be crackling edge search data side work, although there is enough depth, but the threshold is extremely flat, engineering staff can also reuse a lot of existing knowledge. Erlang in this point is actually related to the 1th mishap, most people learn a week is not mind, not everyone's abstract thinking and world view are the same good, so functional programming although not more than the imperative language start late, but always learn very few people, this is history, for most people, but also want to solve the problem, To create value, not mathematically, to deduce.
8, finally, I suggest, if you are playing C + +, now began to learn Golang, is the best time to grow up with a reliable language, this feeling is very good, you use Erlang toss 1 applications, with go I am afraid to complete 10 open source projects, believe their judgments, believe their own logic, Win is win, lose is lose

Original address: http://www.douban.com/note/233256219/