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

[Joe Armstrong]

On Thu, Mar 28, 2013 at 12:26 AM, giovanni_re <john_re@REDACTED> wrote:

> Do you have something valuable to add to these discussions?
>
>

 No - I want to provoke discussion, not take part in it.

 I'll sit back and watch.

I want to start publicizing Erlang - we've had the technical  discussions
 before.

You guys - you who read this list - go tweet and blog - join the
fun.

I came back from the San Francisco Erlang Factory fired with
enthusiasm and immediately started a new blog at

    http://joearms.github.com

The idea was to bang the drum a bit and explain what we're doing
from my point of view.

 I'm now trying to explain what we do in simple terms so that more people can
understand what we're doing.

My second post seemed to attract some attention
with 160 comments on:

https://news.ycombinator.com/item?id=5451202

I'm saying things that a lot of people disagree with, but also
a lot of people agree with - so a lively discussion followed.

So if you love Erlang or hate it go join the fun at ycombinator.
Saying Erlang is great here is preaching to the converted,
time to broaden the discussion and take the argument to the
hurly burly of the marketplace.

I know I'm an opinionated bastard who makes loads of mistakes,
but perhaps we are not totally barking up the wrong tree.

I think it's time to throw a few stones into the pond and see where the
ripples go.

In the next few weeks I'll be blogging my impressions from the Erlang
factory.

I feel like Marco Polo telling tales from far off exotic places.

It's amazing - did you know, they don't have snow in San Francisco
what an exotic place.

/Joe



---
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130329/dae89662/attachment.htm>