7 ms·

The Erlang Rationale

211 points by lelf 7y ago

MaysonL 7y ago
Should be of interest to anybody interested in this, Joe Armstrongs Ph.D. thesis: http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf
- 0_gravitas 7y ago
  I'm about halfway through the meat of it, it gives alot of good insights and Joe's writing style is very easy to read through
  - jeremy_k 7y ago
    Came across it from the reading list on the Alan Kay post. Good to hear its an easy read, might sit down and dive into it tonight.
- vardhanw 7y ago
  Is this better of an introduction to Erlang (and in general distributed fault tolerant systems) than other sources (e.g. programming Erlang)? I come from a telecom background and worked on high reliability/robust systems, somewhat on the principles of this book [1]. Wanting to learn Erlang. [1] Robust Communications Software: Extreme Availability, Reliability and Scalability for Carrier-Grade Systems - Greg Utas
  - rramadass 7y ago
    Am a noob in Erlang studies but i have settled on the following three books. 1) Introducing Erlang: Getting Started in Functional Programming. - Just to get an easy intro. 2) Programming Erlang: Software for a Concurrent World by Joe Armstrong himself. 3) Erlang and OTP in Action - This one seems to be the advanced book.
  - rramadass 7y ago
    What other books would you recommend to study about programming High Reliability/Robust/Fault-Tolerant systems?
fortran77 7y ago
It's a shame that the elegance of Erlang has been distorted with Elixir.
- brightball 7y ago
  What’s been distorted?
  - rlander 7y ago
    "The language should be simple – Simple in the sense that there should be a small number of basic principles, if these are right then the language will be powerful but easy to comprehend and use. Small is good."
    - jeremyjh 7y ago
      Elixir has Erlang semantics + hygienic macros and a few other niceties. Judicious use of macros in libraries can actually make the experience simpler for the developers.
      - rlander 7y ago
        If both languages have the same semantics, why choose the one with more complex syntax?
        keymone 7y ago
        Syntax complexity is highly debatable topic. It involves complexity of parsing (by machine), reading and scanning(by human), conciseness, coherence of syntactic constructs and more things I don’t know. I wouldn’t say prolog based syntax is necessarily simpler than ruby(?) based one in all those categories. Of course only LISPs have achieved syntax perfection, all hail LFE and other lispy fronts to erlang!
- toast0 7y ago
  I don't particularly care for Elixir, but it's kind of nice having more people on the BEAM.
ggm 7y ago
A not very useful level of indirection: it's a blog pointing AT the Erland rationale, not the rationale itself.
jstewartmobile 7y ago
I think the world of Joe Armstrong (may he rest in peace), and was really excited about jumping into this world. In practice, I think this philosophy is better on paper than in the real world. Start with message passing over multiple processes. The Erlang/Elixir ecosystem leans toward lightweight processes and message passing for everything. Isolation is great, but it has a cost. Part of that is paid in reduced inspectability. Good luck getting a meaningful stack trace, or figuring out what someone else's code does, when even the simplest action is split over a half-dozen concurrent processes and supervisor trees. I know it's a bridge that eventually has to be crossed, but a very expensive one!--like pouring the foundation for global HQ before the first customer has even signed. Dynamic typing is another pain point. Wrangling types is not fun, but to keep growing something, they're non-negotiable. Facebook and Hack. Microsoft and TypeScript. The preponderance of C# and Java in the enterprise world, and C++ in games. These weren't accidents of history. Without mandatory compile-time type-checking, re-factoring eventually becomes so perilous that it is avoided, and the product withers. Why they chose that in a "robustness" language is a head-scratcher. Also, the compiler is slow--which wouldn't be so bad if it caught more errors (like type mismatches), but it doesn't.
- elcritch 7y ago
  In my experience the stack traces from Elixir (or even Erlang) are pretty useful. Sure there isn't a full stack trace back to a main function however that really isn't different than a framework with any level of indirection. Given the choice between a C#/Java stacks trace 40 lines deep and a BEAM stacktrace of only 6 lines I'll take the latter. Even better you get both the value of the last received message and the state of the process in the stack trace makes reproducing an issue simple. Based on what you're saying given the lack of inspectability it sounds like you haven't tried out some of the introspection capabilities of BEAM. Maybe you have, but I've seen little that compares to the Observer module that comes included in a language. Realtime introspection of processes and the ability to see the message queue for any process makes inspecting the whole system very interactive and powerful. There's a point that message passing lowers max performance, but given the rise of multicore processors it's pretty powerful platform. Future hardware likely could weaken memory coherency between cores which could be taken advantage of by BEAM. Overall it takes a different mindset to work well with Erlang philosophy IMHO.

211 points by lelf 7y ago

Should be of interest to anybody interested in this, Joe Armstrongs Ph.D. thesis: http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf

0_gravitas 7y ago
I'm about halfway through the meat of it, it gives alot of good insights and Joe's writing style is very easy to read through
- jeremy_k 7y ago
  Came across it from the reading list on the Alan Kay post. Good to hear its an easy read, might sit down and dive into it tonight.
vardhanw 7y ago
Is this better of an introduction to Erlang (and in general distributed fault tolerant systems) than other sources (e.g. programming Erlang)? I come from a telecom background and worked on high reliability/robust systems, somewhat on the principles of this book [1]. Wanting to learn Erlang. [1] Robust Communications Software: Extreme Availability, Reliability and Scalability for Carrier-Grade Systems - Greg Utas
- rramadass 7y ago
  Am a noob in Erlang studies but i have settled on the following three books. 1) Introducing Erlang: Getting Started in Functional Programming. - Just to get an easy intro. 2) Programming Erlang: Software for a Concurrent World by Joe Armstrong himself. 3) Erlang and OTP in Action - This one seems to be the advanced book.
- rramadass 7y ago
  What other books would you recommend to study about programming High Reliability/Robust/Fault-Tolerant systems?

fortran77 7y ago

It's a shame that the elegance of Erlang has been distorted with Elixir.

brightball 7y ago
What’s been distorted?
- rlander 7y ago
  "The language should be simple – Simple in the sense that there should be a small number of basic principles, if these are right then the language will be powerful but easy to comprehend and use. Small is good."
  - jeremyjh 7y ago
    Elixir has Erlang semantics + hygienic macros and a few other niceties. Judicious use of macros in libraries can actually make the experience simpler for the developers.
    - rlander 7y ago
      If both languages have the same semantics, why choose the one with more complex syntax?
      - keymone 7y ago
        Syntax complexity is highly debatable topic. It involves complexity of parsing (by machine), reading and scanning(by human), conciseness, coherence of syntactic constructs and more things I don’t know. I wouldn’t say prolog based syntax is necessarily simpler than ruby(?) based one in all those categories. Of course only LISPs have achieved syntax perfection, all hail LFE and other lispy fronts to erlang!
toast0 7y ago
I don't particularly care for Elixir, but it's kind of nice having more people on the BEAM.

ggm 7y ago

A not very useful level of indirection: it's a blog pointing AT the Erland rationale, not the rationale itself.

jstewartmobile 7y ago

I think the world of Joe Armstrong (may he rest in peace), and was really excited about jumping into this world. In practice, I think this philosophy is better on paper than in the real world. Start with message passing over multiple processes. The Erlang/Elixir ecosystem leans toward lightweight processes and message passing for everything. Isolation is great, but it has a cost. Part of that is paid in reduced inspectability. Good luck getting a meaningful stack trace, or figuring out what someone else's code does, when even the simplest action is split over a half-dozen concurrent processes and supervisor trees. I know it's a bridge that eventually has to be crossed, but a very expensive one!--like pouring the foundation for global HQ before the first customer has even signed. Dynamic typing is another pain point. Wrangling types is not fun, but to keep growing something, they're non-negotiable. Facebook and Hack. Microsoft and TypeScript. The preponderance of C# and Java in the enterprise world, and C++ in games. These weren't accidents of history. Without mandatory compile-time type-checking, re-factoring eventually becomes so perilous that it is avoided, and the product withers. Why they chose that in a "robustness" language is a head-scratcher. Also, the compiler is slow--which wouldn't be so bad if it caught more errors (like type mismatches), but it doesn't.

elcritch 7y ago
In my experience the stack traces from Elixir (or even Erlang) are pretty useful. Sure there isn't a full stack trace back to a main function however that really isn't different than a framework with any level of indirection. Given the choice between a C#/Java stacks trace 40 lines deep and a BEAM stacktrace of only 6 lines I'll take the latter. Even better you get both the value of the last received message and the state of the process in the stack trace makes reproducing an issue simple. Based on what you're saying given the lack of inspectability it sounds like you haven't tried out some of the introspection capabilities of BEAM. Maybe you have, but I've seen little that compares to the Observer module that comes included in a language. Realtime introspection of processes and the ability to see the message queue for any process makes inspecting the whole system very interactive and powerful. There's a point that message passing lowers max performance, but given the rise of multicore processors it's pretty powerful platform. Future hardware likely could weaken memory coherency between cores which could be taken advantage of by BEAM. Overall it takes a different mindset to work well with Erlang philosophy IMHO.