[erlang-questions] 2 Erlang articles @news.yc: 1) Armstrong - Right Problem. 2) Go vs Erlang

[giovanni_re]

Do you have something valuable to add to these discussions?

---

Joe Armstrong: Solving the wrong problem (github.com)
111 points by geoffhill 4 hours ago | 47 comments
 https://news.ycombinator.com/item?id=5451202

 konstruktor 2 hours ago | link > At this point in time, sequential
 programs started getting slower, year on year, and parallel programs
 started getting faster.

The first part of this statement is plain wrong. Single thread
performance has improved a lot due to better CPU architecture. Look at
http://www.cpubenchmark.net/singleThread.html and compare CPUs with the
same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T
scores 1971 points while a July 2008 Intel Core2 Duo T9400 scores 1005
points. This is almost double the score in less than four years. Of
course, one factor is the larger cache that the quad core has, but this
refutes Armstrong's point that the multicore age is bad for single
thread performance even more.

For exposure to a more balanced point of view, I would highly recommend
Martin Thompson's blog mechanical-sympathy.blogspot.com. It is a good a
starting point on how far single threaded programs can be pushed and
where multi-threading can even be detrimental.

Also, I think that fault tolerance is where Erlang really shines. More
than a decade after OTP, projects like Akka and Hysterix are finally
venturing in the right direction.


=== 

 Concurrency Models: Go vs Erlang (joneisen.me)
46 points by geoka9 2 hours ago | 13 comments
 https://news.ycombinator.com/item?id=5451651 
 

 jerf 2 hours ago | link Erlang's error checking model is a great deal
 more like Go's than he thinks. Erlang is in the "exceptions are
 exceptional" camp too, and idiomatic code should not be throwing
 exceptions around willy -nilly.

Go is noticably more fragile with errors. Unhandled exceptions (which
are just a fact of life unless you're a perfect programmer) will result
in the entire program terminating if you don't have something that
handles it. This behavior is forced on it precisely because of the
shared memory model (one of the actual big differences); if one
goroutine has f'ed up, you simply don't know what the state of your
program is anymore. (Theoretically you could do better than that, but
not simply.) Since Erlang memory is isolated, it can kill just that one
process, and the other processes can pick up the pieces. (Not
necessarily perfectly or without loss, but in practice, really quite
well.) Consequently, for any serious Go program, you're still going to
have to choose an exception handling policy, it's not as if it has
gotten away from exceptions. Failures are a fact of life... for all you
know, memory was corrupted. Again, the difference here is not "error
handling policy" but the longer term consequences of shared vs. isolated
memory spaces. If you just type up idiomatic Erlang OTP code, you have
to go out of your way to not have a bulletproof server; if you just type
up idiomatic Go code it's on you to make sure you're not excessively
sharing state and that you aren't going to see your entire server doing
tens of thousands of things come down due to one unhandled exception. Go
programmers need to be more worried about error handling in practice
than Erlang programmers, since Erlang programmers aren't facing the
termination of the entire world if they screw up one thing.

There's also a recurring pattern in newer language advocates in which
they will in one year claim it's a good thing that they don't have X,
and next year tout to the high heavens how wonderful it is that they
just implemented X. I went around with the Haskell world on a couple of
those issues ("no, strings are not linked lists of numbers", "yes they
are you're just not thinking functionally and inductively dude, and by
the way, six months later, check out this totally radical ByteString
library, and when that still turns out not to be stringy enough hey,
check out Data.Text six months later..."). Thinking you can get away
without OTP is likely to be one of those for Go. No. You need it, though
I have questions about whether it can even be built in Go, because one
of the other actual differences between the languages...

... which is Channels vs. Processes. Go has channels, but you can't tell
who or what has them, and there's no such thing as a "goroutine
reference". By contrast, Erlang has processes, but no way to tell what
messages they may send or receive, and there's no such thing as a
"channel". Again, this has major impacts on how the system is
structured, in particular because it is meaningful to talk about how to
restart a "process" in a way that it is not meaningful to talk about how
to restart a "channel".

Go advocates desperately, desperately need to avoid the temptation to
explain to themselves why Erlang isn't as good, because then they'll
fail to learn the lessons that Erlang learned the easy way. There's a
lot of ways to improve on Erlang, but let me tell you that despite those
opportunities, Erlang as a language is one of the wisest languages
around, you do not want to try to exceed it by starting from scratch.
Learn from it, please , I want a better Erlang than Erlang, but talking
yourself into how Go is already better than Erlang isn't going to get
you there.