What's all this fuss about Erlang? (2007)
pragprog.com
pragprog.com
But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.
If your program has sequential or less parallel phases or needs to communicate then you are subject to Amdahl's law like you always were.
Armstrong has that claim in the Erlang book and I was gobsmacked to see it written down with no caveat or mention of the limits from Amdahl's law whatsoever. I was sure it was a joke and it would be followed by 'ha ha ha of course not - nobody knows how to achieve that despite decades of intensive research', but no it's a serious claim made with a straight face. Erlang's solved it!
Erlang helps you write parallel programs... but only if you program is entirely parallel in the first place.
It's sort of like how people talk about how NumPy can be so useful; Python is itself one of the slowest languages (especially since when it comes to NumPy we can't necessarily count on PyPy, though that's coming along) but it doesn't matter because you just use the slow language to script up the computation you want to do, which then goes and runs in highly-optimized assembler implementations. You can look at Erlang being very similar when being used in its native domain for networking, using a slower language to decide how to route bytes around.
So it's quite possible for competent Erlang to beat out competent Java for such a task. Java optimized to within an inch of its life can certainly beat Erlang, but it's going to be a much uglier code base to get there.
Not all available JVMs on the market have "a block the world GC" and the way multi-processing is done is implementation defined.
It does have advances in things like reloading and supervision.
I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well.
I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to originality - as I say Amdahl has done the maths and shows that it is only possible for a program that is embarrassingly parallel.
A better way to phrase this would perhaps would be to say that perfectly preemptive scheduler should be able to keep all cores hot. Blocking of one Erlang process should not halt the program's progress.
As Erlang requires message passing overhead by design, it will never see perfectly linear scaling behaviour. Still, its scheduler, its GC model and M:N threading implementation are extremely robust and can be relied upon to write extremely reliable networked services.
Despite all the arguing I'm taking part in, this is probably the true and reasonable explanation. I read 'should' as 'if it doesn't there's a problem'.
If you recall the famous Wide Finder benchmark for parallel programming by Tim Bray, back in 2007 as well [1], those were essentially the results.
Languages like Erlang or JoCaml (Ocaml plus joint calculus), whose models are inherently parallel yield simple and fast solutions.
Other languages too, but they require a lot of expert optimization and ugly code.
[1] https://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Find...
That's Erlang's main weakness. For parallel code, structurally shared data is immensely useful for processes running in the same address space. With Erlang, you have to give that up.
OTOH, not having this possibility makes distributing processes to other nodes a lot simpler.
And how would you have one of those? Erlang encourages you to design and think about programs in a certain way, that typical C, Java or Python does not. I've seen Armstrong in one of his talks to actually emphasize the importance of learning distributed systems if you wanted Erlang to be useful for you. That's way beyond "embarrassingly parallel" point of view, Amdahl's law has no use here.
> But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.
You've made two claims, one irrelevant and one false:
1. only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.
2. it's trivial to write a program that's faster in X language I'm not sure how toot define trivial, but I've yet to find a language that can communicate between threads as performant-ly. Even languages like Clojure which use similar thread semantics can't do what Erlang can because the underlying threads aren't as lightweight. Spinning up a million threads in Erlang isn't even unusual, whereas in any of the languages you mention it's either crippling-ly slow (Python or Java) or very difficult to synchronize (C most, but Python and Java aren't easy).
OK. Not an Erlang user, but I can't let this statement go.
I've studied parallel numerical algorithms. Many/most of them will involve blocking because you're waiting for results from other nodes.
If you're saying Erlang has somehow found a way to do those numerical algorithms without having to wait, then I'd love to see all those textbooks rewritten.
Amdahl's Law reigns supreme.
>Your Erlang program should just run N times faster on an N core processor
No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.
Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation to spread each part of this workload over not only more cores but more machines across the network.
And then realize that you can deploy updates to this codes individual parts while other parts continue running without taking down the whole system.
Then you get Erlang.
No one's disputing Erlang's prowess at parallelism. What the critic in this thread was saying was that you can only get Nx speedup on an N core processor for a limited set of algorithms. Most parallel algorithms will not fall in this category. Amdahl's law is a general truth - it doesn't matter what your architecture/language is. There is nothing special about Erlang that will make any parallel algorithm scale linearly with nodes.
No, I'm not claiming Erlang breaks Amdahl's Law. I'm claiming that Amdahl's Law applies less often than people think it does.
That's how it works in pretty much any language that supports message passing. I used to do MPI programming in C. Nothing you said is not true for MPI in C. Later I did some MPI in Python. True there as well. If you have MPI in any language, it is true for that language.
MPI doesn't require threads.
I think people here are confusing parallel programming with multithreaded programming. One is a subset of the other.
I can't agree with that, and it's key to my point. There are some problems which we just don't know how to make embarrassingly parallel. Take something classic like mesh triangulation or mesh refinement. Nobody knows how to make those embarrassingly parallel. If you write it in Erlang, it's still not going to be embarrassingly parallel. And it won't scale linearly to N times faster on N cores no matter which language you write it in.
So it's just not true to say that any Erlang program should scale linearly. If nobody on earth knows how to make mesh refinement scale linearly, how will Erlang do it?
Maybe you mean you wouldn't choose to write those programs in Erlang? Well then I think it's a meaningless claim to say Erlang will linearly scale your program, but only if it is a program which is naturally linearly scalable anyway. Erlang hasn't helped you do anything there so why make a claim about it?
Minor nitpick: Erlang uses processes, not threads. Your comment doesn't explicitly say that Erlang uses threads though, so perhaps I'm being overly pedantic.
Erlang has never been a language about amazing performance. It's been about an environment and library that delivers amazing distributed concurrency with shockingly little effort.
This is an amazing accomplishment and should not be undersold. In making unsupported claims about how Erlang has magical parallelism sauce that somehow ignores Ahmdal's law we ignore the real benefits for a fiction.
Yes. Yes we did.
I would claim that even if you use Erlang and distribute it across multiple processes your program doesn't actually exhibit concurrency. If you want to argue otherwise that's fine, but you just push the problem out: your program is "concurrent" but you gain zero benefits of concurrency, and when you distribute it across multiple cores to try to make it run in parallel it might be concurrent but by definition it will not be parallel.
Either way you want to slice it you have a big problem with this line of thought.
Edit: from my experience it is easy to write Erlang programs that exhibit something not exactly the same as, but similar to, this sort of behavior.
You should stop doing whatever it is that you're doing, because you are in the top 0.00000000001% of programmers, in the Universe, and I want to work on whatever multi-billion dollar startup you undoubtedly have going on.
You can trivialize any issue if you ignore all the facts, but it doesn't make your argument have any correctness.
Embarrassingly parallel algorithms are trivial in pretty much every language. That is why is embarrassing.
>And then you also need to implement mailboxes to receive new data
If you did, it is not embarrassingly parallel.
You know, a huge amount of parallel work is done in C/C++. It was the language used for multiple parallel algorithms courses in my university. Being able to do basic MPI type stuff in C does not make you a top programmer. And not being able to do an embarrassingly parallel algorithm in C would ring alarm bells.
Yes... but!
> The hard part is figuring out how to make a problem into embarrassing parallel
The other hard part is the debugging - especially when you fall short in the "embarrassingly" department.
It's not until C11 that the language itself had any notion of multithreading without reaching out to a separate standard - POSIX - and various nonstandard compiler extensions required to implement it all (e.g. for memory barriers to constrain the reordering of code)
I've further found it distressingly frequent that in porting code from one platform to another that basic primitives are plainly broken to the point where I can write unit tests to catch the issue - usually leveraging e.g. ARM hardware and it's weaker memory ordering semantics, a topic which few fully understand.
For example, a "lock free" circular queue one might use to implement a task system to roll your embarassingly parallel programs atop of. Which were indeed lock free - and volatile free - and atomic free - and memory barrier free - and used in parallel from multiple threads...
Even the experts occasionally forget a mutex lock or something. I play catchup with additional static analysis annotations when new compilers expose new options to catch this kind of thing, but...
What I really consider a game-changer for concurrent programming are the dynamic checkers integrated into recent versions of GCC and Clang (and the Go compilers, too). Those make it super easy to flag data races and don't have any false positives. Caveats apply, naturally, as they can only flag those races that actually happen during a particular execution of your code.
While Valgrind and similar tools could do that for years, the difference with TSan is speed. It's fast enough that you can use it all the time during development. Same for AddressSanitizer and the undefined behaviour checkers.
* A better concurrency model. Lightweight processes vs callbacks and futures. Or even channels. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process.
* Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning.
* Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years.
* Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge case.
Some people might prefer Elixir and that's fine, they are great friends. I personally like Erlang, I think it is simpler. Someone new coming from Python or Ruby might like it better and also it has very beginner friendly community. Jose Valim and and other authors really put user-friendliness and approach-ability at the forefront. I really like that, mad props to them.
The Erlang VM is the engine. You can make a beautiful, sleek, aerodynamic rocket, but it ain't going anywhere unless you literally light a fire under its butt. It helps that BEAM helps the rocket go fast :)
Of course, you need some sort of structural piece to hold your engine and your aerodynamic skin in place, lest your rocket crumples itself up into a ball at launch. That's where OTP comes in: providing a robust structure for your rocket.
Last but not least, you need to launch it. Rebar and Mix work reasonably well as launch clamps in this really contrived metaphor. You also have exrm (or Distillery nowadays, I guess) that works as the VAB, in which your rocket is put together so it can be launched.
I personally consider Elixir to have fewer aerodynamic bumps and other sources of drag than Erlang itself, but that's just, like, my opinion, man. Obviously people will disagree with that, and that's fine.
The rocket analogy is a good one, too. What Erlang accomplishes is massive, and Elixir uses and benefits from all of it.
I don't want to downplay what Elixir accomplishes, either ... to use a SpaceX analogy, Elixir and its ecosystem are like the guidance systems and deployable struts that let you land rockets repeatably on a barge in the middle of the ocean. It uses macros to make solving problems with rockets easier and more widespread, and maybe it also increases our ambition because of it. (I'm thinking about projects like phoenix_pubsub especially Tracker, ecto, the 1.4 registry, etc).
Of course, I tend to feel much more productive in Elixir than Erlang, and thus use Elixir way more often than Erlang directly, but I'm able to come at Elixir with a more Erlangy perspective and approach.
(Now, of course, when I see more "traditional" C/Ruby/Perl/Python/Rust syntax, I can't help but roll my eyes, but that's a slightly different subject.)
Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end.
Erlang's:
-module(recursive).
-export([fac/1]).
fac(N) when N == 0 -> 1;
fac(N) when N > 0 -> N * fac(N-1).
You can tell fac(N) both are in a group of pattern matching cause ';' and '.'. The '.' denote the last pattern matching function.
Elixir:
defmodule Factorial do
def of(0), do: 1
def of(n), do: n * of(n-1)
You can't tell because there is no ';' and '.'. This is a trivial case but when your Elixir's module have a tons of function in it, this issue become relevant.
fac(0) -> 1;
fac(N) -> N * fac(N-1).
Or is there a particular advantage to write it using guards?
I would also like to point out that Erlang has also very good support and has seen adoption in some very critical systems as opposed to CRUD web applications which is the main domain of Elixir. Most of Ericsson’s products use Erlang to a certain degree, there are a lot of banking systems and aviation systems which make use of Erlang as well, quite a few Internet companies use it to great success, and many more.
And by the way, the semantic meaning of “;” and “.” is an awful lot similar to their use in the English language, you are blowing it out of proportions. This is a trivial thing which you learn after a 10 minutes introduction to Erlang. For me, personally, if one has a problem understanding the meaning of “;” and “.” or learning a new syntax for that matter, I can easily conclude that I probably should not give that person any decision power in designing systems.
This is the closest Erlang equivalent:
fac(0) -> 1;
fac(N) -> N * fac(N-1).Experience after designing and deploying systems that run 100,000 transactions/sec per box: don't bother with engineers that cannot achieve proficiency in Erlang. Elixir is a crutch, and not something you want to show up with in 400 meters hurdles race. You will look pathetic.
Erlang has its uses and Elixir has its uses. Dismissing Elixir's userbase as 'pathetic' is pretty rude and a disservice to a pretty incredible language. See the Discord article where they clearly demonstrate Elixir and Genstage are ready for production and can be used to write performant services.
I get that you really like Erlang and its quirks, but maybe there are more mature ways of expressing this love than calling Elixir users 'pathetic'.
I totally take your point that everything written in Elixir could be written in Erlang. That much is a fact. However, my point in saying they serve different uses is saying that better syntax in itself isn't nothing. If a language enables many people to grasp actor-based concurrency in an easy to understand fashion, can we reduce that to "just syntax"? I guess my point is that introducing syntactic clarity is in itself a massive feature that shouldn't be dismissed.
I hope that further explains my intent!
And to answer your first question, although I thought I was very clear that I do not want to take part in your discussion with the parent: no, I do not think that you are a bad programmer for learning Elixir, I think if you were to only learn Elixir, call it a day, and then spread the word of how incredible Elixir is, you would be, however. Programming languages are just that, programming languages. The more you know the better and there is no silver bullet. As you will get back to Haskell you will probably come to appreciate its powers. Also, the fact that you have not grasped Haskell’s syntax when you have first tried does not make it a poor functional programming language and it certainly does not make Elixir a better designed functional programming language. That’s just your perception because Elixir was, for you, easier to learn. The fact that I cannot comprehend particle physics does not necessarily make particle physics a badly designed model.
But where would you stop?
If Elixir makes it easier to write fast, concurrent for many people than Erlang, that totally can be discussed. The way you separate developer satisfaction/well-designed syntax from the VM it runs on top of is a separation I dispute.
Obviously these comparisons will never be 100% valid, but I think they make my point: Will you say that Scala is no different (or better) from Java? Will you say that Dart or Elm are no different (or better) from JavaScript? Simply because their underlying architecture is the same?
I think there is some hostility I am sensing from Erlang programmers where there is none given in return. I don't hate Erlang. I'm simply saying a language that can leverage the performance of the Erlang VM shouldn't be dismissed. Again, I never ever said I thought Elixir was better than Erlang. I was just responding to the parent commenter's assertion that all alchemists are pathetic.
Also, I think the implication that may have entered my writing was that because I personally found Elixir easier to learn (and it would be difficult to argue that I am alone in this), it is somehow a better language than Haskell, Erlang, and many other FP languages out there. If that was the implication you drew, I apologise for my a mistake in my writing. Since I learned Elixir, I'm now taking a course in Haskell at my college to better understand these programming languages. Just because I called Elixir incredible, doesn't mean I believe it's the end all be all language!
Again, thanks for your comment. I learned a lot from it.
You misunderstand me. I did not say that Elixir is not different from Erlang, what I said already two times and this is the third time is that you cannot send me to some case study about how code deployed on the Erlang virtual machine performs well at high traffic and imply that the performance seen is a quality of Elixir, because it is not. Can we agree on this? That is the one and only point that I was trying to make, and if you read carefully and want to understand I think I have expressed that thought in a quite clear way. It is also a very factual truth, not a subjective matter, when we discuss syntax preference we do not discuss throughput because throughput is not a quality of the syntax. Even less so in the case of Elixir which runs on top of the Erlang virtual machine. Performance could be discussed as a function of syntax if, for instance, Elixir compiled to virtual machine instructions for the Erlang virtual machine and then had its own layer of optimizations etc. and then there would be some inherent quality of the Elixir syntax which makes those optimizations easier. But the fact of the matter is that Elixir compiles to Erlang which is then compiled to instructions for the virtual machine. Yes, Elixir it’s just syntax, I suggest you read its source code and not take my word for it. There is nothing incredible that Elixir has invented, it just looks like Ruby which made it easier to read by ex-Ruby programmers, that’s all.
Yes, of course I am biased to have a problem towards Elixir programmers making extraordinary claims when they lack cultural knowledge and brag about things that have not been invented by Elixir in any way but are qualities of a system which they very much enjoy criticizing in ignorance. I have even heard Elixir programmers talking about a so-called Elixir virtual machine which I find amazing and tells me a lot about their community and culture.
"By the time the software engineering of a language gets in good shape, the language has become obsolete in terms of 'needed expressiveness'. [Therefore] in a 'Real' computer science, the best languages should serve as the 'assembly code' for the next generation of expression!" [1]
He then proposed the hypothetical question: "What should Erlang be an assembly code for?" [2]
I'm not sure if he knew about Elixir..
[1] https://youtu.be/fhOHn9TClXY?t=30m39s [2] https://youtu.be/fhOHn9TClXY?t=36m49s
* java is unsuitable
* no pthreads, please (wrong concept)
* immutable data (no locks - no problem)
* isolated lightweight processes (share nothing)
* communication by message-passing (grom Kay's OOP)
* dynamic typing (good-enough, quick prototyping)
* pattern matching (on receive)
* supervision hierarchies (fault tolerance)
* reusable components for server development
Doing a < b and taking an action based on that result is as harmful with stale data.
...and while that's true, I'd still like to hear the opinion of someone more knowledgeable because it's an issue that's been bugging me too.
[1] If you touch a lot of ref counted binaries, without generating enough garbage on the process heap to trigger GC. GC time scales with process heap, if you get a large enough backlog in your mailbox, GC may reduce the throughput to the point where you can't recover, although doing selective receives if you don't trigger the optimization for new references[2] is much more painful than GC scaling.
[2] http://erlang.org/pipermail/erlang-questions/2010-June/05175...
EDIT: from slides about r19 GC [3], it seems that both of the GC issues I mentioned have had targeted changes: for refcounted binary issues, there's now a 'virtual binary heap' to help trigger GC; for GC with a big mailbox, there are different allocation strategies available which may help.
[3] https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co...
Now that I think of it, Canonical's push toward "snaps" (sandboxed and vendored—but not fully containerized—software bundles, as a package format) might bring a flourishing of Erlang-based application software, given that it's much more compatible with Erlang's style of release-management.
The release process I've used for Erlang before packaged things up into a folder with everything you needed to run.
edit: There's this (abandoned, for reference): http://www.oocities.org/erlang_journal/sae.html
I also played around with an idea of bunding the release into a self extracting bundled executable too https://gist.github.com/tsloughter/d62aad6d67b263e69275376b1...
I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim would have served it better — but it's certainly a step in the right direction.
The Erlang toolchain has a ton of ergonomic issues that could have been polished down a long time ago, but haven't been. Erlang simply feels oddly quirky and antiquated for anyone used to modern GNU tools or modern REPLs.
For example: Lack of Readline support (needs rlwrap to be usable, at least on Ubuntu), lack of GNU-style long options, the obnoxious ctrl-C behaviour that doesn't respect Unix conventions and gives you a prompt with confusing options (quick, what's the difference between "abort" and "kill"?) that seem aimed at developers and are completely wrong if you're just a user of an Erlang tool. (Couldn't they have relegated this to USR1 or something instead of INT, like a normal program?) On the server, the epmd process is a thorn in the side of any system administrator. Erlang devs also seem to think that emitting Erlang stack traces is a good replacement for proper English error messages, and if you're not an Erlang dev, you haven't seen stack traces until you've seen the kind of monstrous, obscure, deeply nested contextual dumps that Erlang programs can produce.
And so on. Little things, but important things that can completely kill the joy when you're a potential adopter.
Erlang shouldn't need Elixir to modernize, but there's probably very little incentive within the community to change quirks that they're all used to dealing with by now.
(I encountered similar issues with OCaml, which has many parallels to Erlang: Quirky, odd syntax, antiquated toolchain, etc. Facebook's cleanup effort [1] looks very promising.)
Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).
It doesn't just have its own syntax, it has its own idiosynchratic, somewhat alien way of doing almost everything that is already established on Unix. The difference feels almost as stark as Linux vs. Windows.
Honestly, I think that if Ericsson was just starting to build Erlang today, it'd look less like a self-contained emulator, and more like a virtual-machine image. (Or more than one: maybe an Erlang unikernel image ala Erlang-on-Xen, and then companion POSIX VMs to spawn ports on, making the Erlang cluster into its own Kubernetes-alike.)
EDIT: found the link http://erlang.org/pipermail/erlang-questions/2011-October/06...
But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterprise-y bloatware-apps and business-process servers that make Java's market-share so large.
Because Enterprise software gets designed top-down, how excited developers are to be using the (dictated) language aren't very relevant. How easy the language is to learn is relevant; how many engineers you can either hire or train to code in the language is relevant. But whether they enjoy their day-to-day lives writing in the language isn't, really.
Thus, I think, why things like deployability are more important to Erlang: for the type of software projects Erlang would be good for, considerations like deployability (and maintainability, remote debugging, easy hot-patching, etc.) are what guide language choice. Erlang wins on most of those fronts (as it should: its OTP framework is effectively "30 years of ops best-practices constraining development"), but for various reasons, [non-embedded] deployment has always been a pain-point.
Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data processing where a lighter language like Ruby will not do well. There's nothing in Erlang that conceptually prevents it from being a general-purpose language; it's just that its ergonomics don't really "scale down" to the stupid, simple stuff.
I remember, years ago, trying to write a basic parallel non-OTP log-processing pipeline for some log files, thinking Erlang would be ideal... and being surprised at the number of roadblocks I had to deal with. Around the same time, Tim Bray went through the same process, but spent a lot more effort on it than I [1].
[1] http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang
(Though, even in that setup, there's no way to get an effect equivalent to requiring un-bundled gems from your script in Ruby.)
For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Neither relx, nor rebar, nor erlang.mk, etc. were born out of said commercial entity, despite those kinds of things being perfect candidates for a services company to produce to make their own lives and the lives of potential new users easier.
There have been some huge high-profile Erlang use cases that would normally feed a Silicon Valley/Hacker News style hype-cycle, but somehow those came and went with almost nothing to show for it. It almost feels like if Elixir hadn't shown up on the scene to attract new users and splinter off a chunk of the massive Ruby community that the Erlang side of the world would all but dead already. Sometimes I wonder how it is one goes about blowing a 15+ year technology lead and 10 years of huge and publicly visible wins, but that's sorta what's happened.
In the curation of said community there's also been an overtone of nostalgia for "the good old days" & "yeah, that part is supposed to be painful", and a sort of long-running tone deafness around on-boarding, usability, general-developer-ecosystem-friendliness, etc. complaints that certainly could have had a lot more done to be ameliorated by the commercial entities who stood to gain the most by Erlang having broader adoption.
Frankly, much like Elixir breathing a bit of new life into aura around Erlang, if it weren't for people like Fred, Tristan, Alisdair, Garrett and a few others (who again aren't part of the core supports for Erlang commercially) being really passionate against all odds about making Erlang easier to use, and to explore new use cases, and to meticulously and engagingly document all of it... Erlang would probably be dead already.
All of which might be overly harsh, but I'm having a very acute existential crisis around Erlang at the moment. I love it. I love developing in it. I love introducing it to teams and projects. And as time goes on I feel rapidly and increasingly more guilty about that given the decline it seems to be in and has been in if I'm being honest with myself in retrospect.
Blargh :-(
edit: look at the increasingly dwindling sponsors list of Erlang Factory San Francisco over the last several years as an indicator of the above rant/cry-for-help.
That's what I mean by "deployability": the hell that is trying to convert your Erlang release into a distro package so that users can simply "apt-get install" it and have the distro maintain it for you; and so other software packages can declare package-level dependencies on it.
The reason that true static binaries ala Go would be better, is simply that it would stop the distro maintainers from messing with everything to quite the same degree. In such a setup, there wouldn't be a "system Erlang runtime", because Erlang would just be a baked-in part of /usr/bin/riak or /usr/bin/ejabberd. (Which wouldn't stop distros from making Erlang SDK packages for things like an Elixir package to depend on, but they wouldn't be involved at all in the dependency tree of the Erlang-release-derived packages on the system.)
Of course, when people install your software "manually", you can distribute it however you like—a zip of an Erlang release, like a Java JAR, is already quite a convenient format for such installations all on its own. But when people want to install something that depends on your software (like, say, OpenStack depends on RabbitMQ), they don't want to spend nearly as much time thinking about your package. They don't know you exist, and they don't want to know you exist—they want the distro to handle that detail for them. So you're stuck fighting the distro. (And things like OpenStack are stuck doing non-distro-packaged releases to avoid the problem.)
Which brings me back to my original point: "snaps" are promising not because they sandbox packages, but because they're a countervailing philosophical movement on how software should be packaged. A distro that supports snaps is a distro that has made room in its heart for packages that don't want to break things down into little FHS-arranged dep-graph-divided bits. It gives them an out, a place to put these packages rather than just denying them outright.
Programmers writing dynamic websites are likely to post questions on Stack Overflow. Questions on Stack Overflow create mindshare, mindshare attracts more serious programmers who can improve the ecosystem by writing generic network services. Language prospers, cycle repeats.
JavaScript is the most popular language on Stack Overflow and React is the fastest growing technology.
Without the dynamic website programmers the cycle short circuits and you end up with a terrible "new user experience" from lack of answered beginner questions and lack of interest building on the non-existent ecosystem.
However what I'm wondering is...there's other vendors and Ericson isn't powering the entire network. What software stacks are used by other vendors? I'm assuming it's mostly C-ish stuff with some ASM sprinkles like in Cisco IOS?
Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off.
I suspect other languages are going to fold the good parts of Erlang/BEAM into them and limit its long-term adoption.
A lot easier said than done, because there are a lot of really fundamental decisions about Erlang that make it what it is. You can't just slap on a scheduler for instance, or Erlang style processes.
Go is probably the closest thing, and it's still lacking some things like the supervision tree.
Erlang is certainly not 'the answer' in terms of computationally intensive anything, for the foreseeable future.
But that article is a bit hype-y.
From what I've read, Go's runtime just isn't compatible with the kind fault-tolerance that Erlang provides (nor was it meant to). It lacks process monitoring, lacks process isolation, has a pause-the-world garbage collector, etc.
Not a knock against Go, just pointing out that the design goals were different.
What they haven't done (or to the extent that other languages have) is make the language and runtime accessible to the broader programming community. The result is that the people who (start to) use Erlang are the kind of people for whom no other tool will help them solve their problems.
Although I have not used Elixir, it seems to me that it was designed as a language that is easy enough to adopt for the wider programming community, while still leveraging the concurrency, fault-tolerance, etc. provided by BEAM and OTP. On top of that, the Elixir community has worked hard to provide the tooling and support developers typically expect these days[0].
This is not to say that Erlang should be radically altered or abandoned. I like the Erlang aesthetic and ethos, and I think the community knows the way it needs to evolve. It is just that I expect more people to come to BEAM and OTP through Elixir than Erlang, and I think it is that platform that should really be the focus.
[0] to their credit, the Erlang community has definitely improved in this area.
Anecdote: I used Erlang, over the course of several years, for very-high-level bot behavior and multi-player mission control, where performance was much less important than the things Erlang provides, but I still had issues with it. Nonetheless, I felt it had given me great leverage, and I thanked Joe Armstrong profusely, when I met him at a conference. Later at the con, I asked a panel whether there were active efforts at improving performance, perhaps with a JIT. They seemed to take it as an attack, and suggested that if I need performance, I should use another language. I mostly write in Clojure now.
I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel.
It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so.
For what value of "mostly scale as well?" For me, that means doing a little extra design/architecting to break out your Golang server process into multiple worker processes.
it's 10 years later and we haven't seen massively parallel architectures take off.
Because there are still barriers that are a bit too large. You either wind up having to do weird things to do what amounts to efficiently passing data between cores, or you end up using a slower language that's a bit far from the computing mainstream.
In my current server, I'm basically sharding my space-game into star systems, with free travel between star systems though "Hyperspace." There is a farm of "worker processes" that is coordinated by a master server. Any instance of a star system can be idempotently spawned when a client is attached to it. < https://www.emergencevector.com >
I think Go is a good option for writing a game server. You'd have to be pretty profligate to make the GC pause overrun one 16.66 ms tick, and if you miss a tick here and there, who cares?
Is there any reason why you do update() in parallel? There is certainly some interesting challenges to solve there but did you have a reason to make it parallel other than intellectual curiosity (e.g. better performance)?
Afaik a game loop's update() is not the intense part in the game loop (maybe that's different for games with lots of world information update, like roguelikes), but rather render() and IO() are so I am wondering what your design thoughts are.
I wanted to come up with an architecture that could support an arbitrarily large world given enough resources. Up to a certain density (from 150 to 250 users per "subgrid") I was close to succeeding.
Afaik a game loop's update() is not the intense part in the game loop but rather render() and IO()
"Render" in the context of a server like this is the IO. One thing you should know, is that this game supported Conway's Life cellular automata at 12 frames/second, completely shared and multiplayer.
Comparing a bare-metal-but-with-GC language like Go to a miniature operating system like Erlang isn't quite fair -- in comparison, Go is missing an actor model, buffered CSP, crash supervision, hot upgrades, remote console/tracing/debugging, and built-in clustering (to name a few).
Once other languages adopt "enough" of the BEAM featureset, they'll have similar performance.
The actor model is a choice of implementation. Crash supervision stands out, but that's not necessary and is part of the Erlang culture - let it crash. It's not as important in other languages with a different underlying belief about errors.
What features mean BEAM must necessarily be slow?
Just to be clear: I really like Erlang. It obviously has different features than a lot of languages and most are aimed towards a certain goal: uptime. But if you can give just a little on that (and you might not have to at all), you can get most of those advantages with a different feature set.
I wonder out of the Erlang experiment which are the objectively better features and which are just really cool?
I find it is not. But of course the right tool for the right job. Multiplying matrices as a single batch process is probably not going to work very well. But I saw it works exceptionally for highly concurrent workload.
This is not just "I ran a quick benchmarks on my laptop and then extrapolated by using an multiplier". Distributed systems work funny and they don't scale linearly. Sometimes a very fast, small sequential program will hit a wall and barf on itself when faced with multiple concurrent requests.
The other secret sauce is not multi-core capability but process isolation. The reason is this: a large distributed system is only as useful / practical as it is fault tolerant. It doesn't matter if you run hand tunes assembly routine and process 1M requests per second, then it crashes every day and you have hours of debugging and downtime. The average throughput or uptime will be pretty bad.
This is one key insight into what makes Erlang (and Elixir) a good tool for distributed systems - fault tolerance is built into the core of the platform.
Tens of millions of concurrent unrelated clients, embarrassingly parallelizable, scales linearly with number of cores, as these share nothing.
> Our site has been optimized for use with newer browsers. We also require that your browser has JavaScript enabled.
> It looks as if your browser has JavaScript disabled.
> This site has information about enabling JavaScript, if that's something you want to do.
Really? I am just trying read a few paragraphs of text on a fairly static-looking site.
<noscript>
<meta http-equiv="refresh" content="2;url=https://pragprog.com/no_js">
</noscript>Ah! No, Joe, that's what you do.
Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe.
And yes, that was already true in 2007.
tl;dr: Don't be that programmer :)
(Also, Erlang has a compile-time static type checker, if type safety is something you're after.)
def some_function(SomeStruct{} = some_struct) do
some_struct.foo + some_struct.bar
end
def some_function(SomeStruct{foo: foo, bar: bar}) do
foo + bar
end
Between this and protocols, I very rarely feel the need to reach for something like Dialyzer. YMMV, of course.
def handle_info(msg, state) when is_tuple(msg) do
# ...
end
As an aside, comparing:
{:ok, port} = Port.open(...)
port, err := port.open(...)
if err != nil {
panic(err)
}
def handle_info([], state = {ppid, _port}) do
Supervisor.stop(ppid)
{:noreply, state}
end
One reason is RAM consumption: while Facebook has bought tremendous amount or RAM for caching content so those extra copies of objects don’t hurt, desktop or embedded apps have different resource constraints.
Another reason is performance. Memory allocation/deallocation is not free. RAM bandwidth for copying those objects isn’t free. Also mutable objects generally more cache-friendly, a modified object stays in the same RAM address i.e. stays cached.
You can have immutability without data duplication; in an immutable-only environment, every process/thread/whatever that uses a specific object can safely reuse a pointer to that object and always know that the object represented by that pointer cannot change under their noses. It's only when you need to "modify" that object (read: create a new copy) where you start to see RAM consumption issues, and even that can be mitigated.
Linked lists are an example of where this works remarkably well; if you have a list (E→D→C→B→A) and want to append F to that list, you can do so trivially without needing to mutate or copy the original (since all you need for the new list is F and a pointer to E). Same if you wanted to replace E with F; just have F point to D instead.
> only when you need to "modify" that object
Well, unless you’re modifying your data, almost all data structures are fine for multithreaded access.
> Linked lists are an example of where this works remarkably well
Linked lists are an example of what you don’t want to use if you care about performance even a tiny bit.
On modern hardware, random memory access is slow. A ballpark estimate is 100-200 CPU cycles just to read a single value (16 bytes for dual-channel DDR) from RAM. With a linked list you pay that cost with each iteration to the next list element. Very expensive.
The fact is that still today, we have millions and millions of lines of code that work in parallel and a crushing majority of it is operating in mutable languages (C++, Java, Javascript, C#, ...).
Pushing immutable languages as the silver bullet to solve concurrency problems is trying to solve a problem that nobody has.
We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past.
That Erlang forces you to build a shared nothing system is the real win for concurrency. Of course, you can do that with other languages too.
> We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past.
Erlang can do fork/join, the schedulers can work steal, and erlang processes are approximately equal to coroutines -- I don't understand what you think is stuck in the past (other than the Prolog like syntax, but you get used to that).
Immutability is a big win for garbage collection and memory allocation however, since there are no circular references, mark and sweep isn't required and a simple (generational) copying collector can be used instead.
[1] actually you can look at other processes' dictionaries if you want, but that requires a lock on the destination process.
>Ah! No, Joe, that's what you do.
I don't know if Joe is a religious man, but I don't believe beseeching the Almighty was one of the reasons listed for why an Ericsson switch was able to achieve nine 9's of availability.
> Most of developers have figured out how to do concurrency and parallelism with mutable state and locks.
It appears to me that the industry has moved to a combination of promises, message passing, thread-safe data structures, transactions, etc., instead of code that directly manipulates locks.
>...as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe.
Depends on what you mean for scale. If you mean "suitable for gargantuan code bases and development teams" then it might not be the best. If you mean "suitable for processing large volumes of requests/events with low latency" then Erlang should be fine.
Types are nice, and I try to heavily leverage the type analysis tools that are available for Erlang (e.g. dialyzer). Java & C# (the two main static languages) are OK, but presence of null pointer exceptions and absence of sum types, intersection types, tuples, etc. really makes righting terse, type-safe code a chore.
Sure, it can be hard to read because you can write the same thing in tens of different ways and some people abuse it, but if you don't and your team does not, you end up with a beautiful code base.
This has to be sarcasm, right?
Based on my experience of almost a decade in the embedded/safety space, this isn't true. Based on my experience as an end user of software on computers, phones, and tablets, I'm also not inspired by the crashes and performance snags I see. Even when it's safe, it's often slower than necessary thanks to unneeded locks by being too conservative (or due to refactorings which made the locks unnecessary but still present).
I agree it's not too hard. But it requires more thought and deliberation to make concurrent code in C/C++/Java than in Erlang than most developers seem willing to commit to the task. Paired with the built-in features of OTP to the Erlang platform, it beats the stock distribution of many other languages for reliability/safety of concurrent code. Those depending on external libraries can never seem to agree on just which one to use. It's too faddish to be reliable for maintenance over the next decade or five.