A while ago there was a thread asking for experiences for people who regret using Elixir. One of the most popular answers was that Erlang is now kind of obsolete because all the things it offers are now available with technologies like Kubernetes and other things.
The thing is however, with Erlang you get all of that in a pretty easy to learn language and it will scale to practically anything. Erlang is also an incredibly productive language. You can get a whole lot of things done in a short amount of time.
I am learning Elixir... and I really get a kick out of it. It's zany and pushes me to bend my brain.
It's like sort of Dr Seuss riff for an experienced programmer.
So you've done a lot of program?
Can you, can you, without a reference?
Could you, could you, with nary a pointer?
Will you, will you, use no return?
No for loop? And less control flow goop?
I had to switch back to do some Python and Swift maintenance/development last week after 2 solid weeks of climbing the Elixir newbie staircase, and I was amazed at how much code I write in "normal" languages whose sole purpose is to decide where the code goes next. For the first hour or two my brain kept screaming "why do you keep putting all of these if blocks everywhere?!"
I always remember Joe Armstrong's quote (which is an adaptation of the of Greenspun's tenth rule):
“Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.”
That is, while other languages and systems barely scratched the surface in terms of distributed programming, Erlang was perfecting all the models needed for it, because that's what it was built for. So everyone else is now playing catch-up with Erlang.
Could you find the link? I'm not sure kubernetes can really replace erlang. Some of the key things that distinguishes erlang are
- light "threads" and supervision of them
- OTP which is largely a library other languages with message passing and light threads could implement
- garbage collection per light "thread" rather than stop-the-world
Akka was on the right track in supporting the same approach to highly concurrent and fault tolerant software. The JVM might have gotten better at garbage collection without paid plugins since 2015 when I last used Erlang?
But I'm curious what stack in particular is seen as superceding erlang.
I went from working with Erlang to working with Java/K8s microservices.
While I understand there are some path-dependent reasons for why we ended up where we are at, but setting up a new service as part of an Erlang release is just an order of magnitude simpler. It's not even close.
I read the same article then realised that the author didn't understand the full capabilities of OTP and maybe had a bit of survivorship bias from kubernetes hostage experience.
I don't remember seeing Erlang as the main criticism against Elixir.
The common problems as far as I recall:
1) Stale or missing libraries
2) Small community (hard to hire, missing resources)
3) High learning curve (Genservers, OTP etc) and the fact you basically need to learn 2 languages at once (Elixir and Erlang).
"The thing is however, with Erlang you get all of that in a pretty easy to learn language and it will scale to practically anything."
But as I said in that thread, that's actually one of the traps.
While Erlang/Elixir as languages and runtimes will scale to "practically anything", a lot of the technologies in the Erlang stack don't. Mnesia is almost useless, if not totally useless. Erlang's not the slowest language, but it's not very fast, and using something 5-10x faster can "scale" nicely too by needing that many fewer systems in the first place. The message system is not what I'd call best-of-breed anymore; very ahead of its time, but most messaging APIs have more functionality in them now for a reason. Erlang is 1-or-none and 1-or-many seems to be the choice winning out in general.
As long as you stay in the ecosystem you're OK, but if you're using Erlang to speak to a non-Erlang DB, to interact with a non-Erlang message bus like Kafka or something, to call APIs from non-Erlang systems and provide APIs to non-Erlang systems, all this integration becomes more a trap than an advantage. Plus Erlang's type system starts to become a bear in those contexts; Erlang's types integrate well with Erlang, but are just quirky enough that it's a pain to integrate with anything else. There isn't even a clean embedding of JSON into Erlang types. (Erlang, like many functional languages of the era, made the mistake of defining a "string" as a "linked list of numbers representing characters", which makes lists ambiguous as to whether they are lists or strings.) Interaction with non-Erlang systems is always kind of a pain because of the lack of clean embeddings into the Erlang type system.
In 2005, scaling to "practically anything" was a pretty decent advantage for Erlang. Scaling to "practically anything" is table stakes for a language/runtime now. Someone else says languages are "catching up" to Erlang, but to a large degree, they have, and exceeded it in many places. To be honest I think it's Erlang trying to catch up now. And it can't. It's too integrated, too opinionated. What was absolutely an advantage in 1999 and 2010 is now a significant disadvantage.
From my experience, even though we deploy with Kubernetes, they complement eachother just fine. When writing code, I can easily partition things into processes, which makes total sense from pure application development viewpoint. Whether Kubernetes does its own thing on top or not, does not matter to me.
I wouldn't spawn and kill thousands of processes with Kubernetes. That's a bit heavy-handed. A couple of Erlang pods that do the same? Sure.
How can Erlang and Kubernetes be compared at all? I actually don’t understand that.
Erlang is a programming language that allows message passing between concurrent actors. Are you saying that, containers are comparable to actors, and that using IPC between them is equivalent to message passing?
Maybe - but that requires the internet to work. That’s a pretty large dependency to bring into what Erlang does in a single process.
I think the idea that you don't need k8s if you have Erlang isn't entirely wrong, but it also does people a disservice by making them sound equivalent when they complement each other really well.
K8s is like an additional level of supervisor that applies to an entire node, and provides really easy scaling and clustering. It's a great tool to run an Erlang app, especially if you already have a managed k8s cluster anyway.
I had a pleasure to watch an amazing talk from Joe Armstrong at Reaktor Breakpoint 2015 in Helsinki.
The funniest part of the talk was when Joe presented a diagram showing the stock market value of Ericsson being up always when he was working at Ericsson. :-D
I even had a chance to have a beer with him afterwards and talk about some programming ideas related to audio programming and also some related to typography!
RIP Joe Armstrong, you were an amazing person and programmer.
> The language grew and evolved and somewhere along the line acquired a name, Erlang, named in honor of the Danish mathematician Agner Krarup Erlang (1878- 1929) whose name is associated with the telecoms industry.
Huh, I always assumed it was a portmanteau of Erricsson and Language.
Unfortunately, Pony has not shown up much lately on HN or Reddit (or Twitter, or anywhere I used to hear about it) but it is a very neat language based on Actors:
Given its support of functional language, built-in fault-tolerance, asynchronous message passing, and scalability, one would assume that it should ride the current wave of distributed computing. Any reason why it is relegated to a niche technology?
No large company pushing it (it came out of Ericsson, but it was never meant as a mass market language from their eyes, so it was really only its creators pushing it), strange syntax (Prolog rather than Algol/C derivative), FP with immutability (so common things like for loops don't exist, making it feel alien to the common dev), and the benefits being things that require understanding and likely experiencing to really value.
[+] [-] rapsey|4 years ago|reply
The thing is however, with Erlang you get all of that in a pretty easy to learn language and it will scale to practically anything. Erlang is also an incredibly productive language. You can get a whole lot of things done in a short amount of time.
[+] [-] travisgriggs|4 years ago|reply
It's like sort of Dr Seuss riff for an experienced programmer.
So you've done a lot of program?
Can you, can you, without a reference?
Could you, could you, with nary a pointer?
Will you, will you, use no return?
No for loop? And less control flow goop?
I had to switch back to do some Python and Swift maintenance/development last week after 2 solid weeks of climbing the Elixir newbie staircase, and I was amazed at how much code I write in "normal" languages whose sole purpose is to decide where the code goes next. For the first hour or two my brain kept screaming "why do you keep putting all of these if blocks everywhere?!"
[+] [-] anhner|4 years ago|reply
“Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.”
That is, while other languages and systems barely scratched the surface in terms of distributed programming, Erlang was perfecting all the models needed for it, because that's what it was built for. So everyone else is now playing catch-up with Erlang.
[+] [-] jbothma|4 years ago|reply
- light "threads" and supervision of them
- OTP which is largely a library other languages with message passing and light threads could implement
- garbage collection per light "thread" rather than stop-the-world
Akka was on the right track in supporting the same approach to highly concurrent and fault tolerant software. The JVM might have gotten better at garbage collection without paid plugins since 2015 when I last used Erlang?
But I'm curious what stack in particular is seen as superceding erlang.
[+] [-] lliamander|4 years ago|reply
While I understand there are some path-dependent reasons for why we ended up where we are at, but setting up a new service as part of an Erlang release is just an order of magnitude simpler. It's not even close.
[+] [-] silly-silly|4 years ago|reply
[+] [-] joelbluminator|4 years ago|reply
[+] [-] jerf|4 years ago|reply
But as I said in that thread, that's actually one of the traps.
While Erlang/Elixir as languages and runtimes will scale to "practically anything", a lot of the technologies in the Erlang stack don't. Mnesia is almost useless, if not totally useless. Erlang's not the slowest language, but it's not very fast, and using something 5-10x faster can "scale" nicely too by needing that many fewer systems in the first place. The message system is not what I'd call best-of-breed anymore; very ahead of its time, but most messaging APIs have more functionality in them now for a reason. Erlang is 1-or-none and 1-or-many seems to be the choice winning out in general.
As long as you stay in the ecosystem you're OK, but if you're using Erlang to speak to a non-Erlang DB, to interact with a non-Erlang message bus like Kafka or something, to call APIs from non-Erlang systems and provide APIs to non-Erlang systems, all this integration becomes more a trap than an advantage. Plus Erlang's type system starts to become a bear in those contexts; Erlang's types integrate well with Erlang, but are just quirky enough that it's a pain to integrate with anything else. There isn't even a clean embedding of JSON into Erlang types. (Erlang, like many functional languages of the era, made the mistake of defining a "string" as a "linked list of numbers representing characters", which makes lists ambiguous as to whether they are lists or strings.) Interaction with non-Erlang systems is always kind of a pain because of the lack of clean embeddings into the Erlang type system.
In 2005, scaling to "practically anything" was a pretty decent advantage for Erlang. Scaling to "practically anything" is table stakes for a language/runtime now. Someone else says languages are "catching up" to Erlang, but to a large degree, they have, and exceeded it in many places. To be honest I think it's Erlang trying to catch up now. And it can't. It's too integrated, too opinionated. What was absolutely an advantage in 1999 and 2010 is now a significant disadvantage.
[+] [-] emerongi|4 years ago|reply
I wouldn't spawn and kill thousands of processes with Kubernetes. That's a bit heavy-handed. A couple of Erlang pods that do the same? Sure.
[+] [-] amw-zero|4 years ago|reply
Erlang is a programming language that allows message passing between concurrent actors. Are you saying that, containers are comparable to actors, and that using IPC between them is equivalent to message passing?
Maybe - but that requires the internet to work. That’s a pretty large dependency to bring into what Erlang does in a single process.
[+] [-] ramchip|4 years ago|reply
K8s is like an additional level of supervisor that applies to an entire node, and provides really easy scaling and clustering. It's a great tool to run an Erlang app, especially if you already have a managed k8s cluster anyway.
This article describes it well: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...
[+] [-] tommica|4 years ago|reply
[+] [-] davidw|4 years ago|reply
Mmmm it's not quite that simple. Erlang requires thought and effort to scale, same as anything.
[+] [-] daitangio|4 years ago|reply
- "failure happens"
- "think asynchronous"
- "processes, not objects"
and Joe had a very nice email on it [2].
K8s is "the way" but also very complex (it does not shield you from the low-level network complexity, like Erlang does).
[1] https://gioorgi.com/2015/erlang-lesson1/
[2] http://erlang.org/pipermail/erlang-questions/2015-April/0841...
[+] [-] peterhil|4 years ago|reply
The funniest part of the talk was when Joe presented a diagram showing the stock market value of Ericsson being up always when he was working at Ericsson. :-D
I even had a chance to have a beer with him afterwards and talk about some programming ideas related to audio programming and also some related to typography!
RIP Joe Armstrong, you were an amazing person and programmer.
[+] [-] atulatul|4 years ago|reply
From the talks I have seen (youtube) I wonder how would it be if Joe had Rich Hickey's presentation/ communication skills.
[+] [-] skavi|4 years ago|reply
Huh, I always assumed it was a portmanteau of Erricsson and Language.
[+] [-] skrebbel|4 years ago|reply
[+] [-] sbuttgereit|4 years ago|reply
https://en.wikipedia.org/wiki/Erlang_(unit)
So, yes, a clever name all around.
[+] [-] canadianfella|4 years ago|reply
I’m sure it’s both.
[+] [-] peterhil|4 years ago|reply
[+] [-] NL807|4 years ago|reply
[+] [-] brabel|4 years ago|reply
https://www.ponylang.io/
[+] [-] nesarkvechnep|4 years ago|reply
[+] [-] delta1|4 years ago|reply
[+] [-] macintux|4 years ago|reply
https://gist.github.com/macintux/6349828
[+] [-] rkhacker|4 years ago|reply
[+] [-] lostcolony|4 years ago|reply
[+] [-] cmrdporcupine|4 years ago|reply