9 ms·

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 obsolet

by rapsey 5y ago

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.

jbothma 5y ago
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.
- rapsey 5y ago
  It does not have that much content in this regard really. https://news.ycombinator.com/item?id=27192873 https://news.ycombinator.com/item?id=27192873
  - jbothma 5y ago
    Ah yeah. I'm using python now for the same reason. I don't need more concurrency than a couple of servers with a few web threads and worker threads would give me. PAAS level deployment and failover is sufficient. (Edit: for my needs at the moment) If you keep your async tasks in memory in any system they'll disappear when you deploy. So they weren't really reliant on the things that set erlang apart. So the cost of the small support base in tooling and libraries is more significant.
    - devoutsalsa 5y ago
      Speaking only for myself, I really start to miss the concurrency options in Elixir when I start coding in something else. I start trying to mash concurrency into the other language & dreaming of GenServers & receive functions.
      - jbothma 5y ago
        I miss pattern matching
      - mycall 5y ago
        Have you look at the actor model inside DAPR?
  - blackshaw 5y ago
    OP may have also been thinking of this older thread: https://news.ycombinator.com/item?id=23283675 https://news.ycombinator.com/item?id=23283675
- AtNightWeCode 5y ago
  Akka, Erlang, Service Fabric and so on are based on the Actor Model. You can implement that pattern in any modern language I would say. It is good when it comes to concurrency handling and it can be very simple to understand and to use but async programming is the modern way to solve many of those problems.
lliamander 5y ago
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.
- jimsimmons 5y ago
  I don’t understand. Which way is simpler?
  - lliamander 5y ago
    creating a new service in Erlang.
  - radiospiel 5y ago
    "setting up a new service as part of an Erlang release is just an order of magnitude simpler." Maybe this is something to consider: by the use of gen_servers erlang/elixir allows mere developers to build a service, which in the end is just a (lightweight) process managed by OTP (the erlang runtime, so to speak). No ops involved.
silly-silly 5y ago
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.
tommica 5y ago
That is one the reasons why I want to build something with it - it is super exciting!
travisgriggs 5y ago
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?!"
- 1MachineElf 5y ago
  I really felt that story. Mind if I ask, where are you working and what was the Elixir project?
  - travisgriggs 5y ago
    The project is ongoing; I work at an automation company :)
- truth_ 5y ago
  What are the best resources to learn Elixir for a programmer? And what are you using?
  - ddek 5y ago
    I liked the book ‘Elixir in Action’. It shows some of the language then immediately jumps into building a way too overcomplicated program (a distributed TODO list) that nicely shows off the features of elixir. After that I just read some codebases. I find elixir codebases extraordinarily easy to read. The language does a great job of making ‘the good way’ also ‘the easy way’, and the linear nature of functional code is much clearer than the usual indirect dependency injected hell. Papercups is a fairly good starting point I think. I liked the livebook codebases too.
  - 5y ago
emerongi 5y ago
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.
joelbluminator 5y ago
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).
- 1_player 5y ago
  Last point isn't true. I've been working full time with Elixir for 3 years and I can't write any Erlang. I can read it, just because it's not that complex syntactically. But I should learn Erlang eventually.
  - lostcolony 5y ago
    I'll say the high learning curve statement isn't really true for Erlang either. I was up and running with Erlang as a mid level dev back in 2013 or so within 2 weeks. Worked through LYSE, and basically grokked everything I needed to, genservers and OTP included. Only thing tricky after that was building a release (since at the time the best tooling was rebar; Elixir's mix makes this really simple).
  - dnautics 5y ago
    same, I can read erlang extremely effectively. Even better than some erlang devs. I can also patch erlang libraries (I fixed my friend's http library to be able to do streaming http 1.1). I can't write it, though.
- linkdd 5y ago
  Erlang's syntax is so simple I've been able to read the source code of RabbitMQ before even knowing the language. Quickly going through https://learnyousomeerlang.com/ https://learnyousomeerlang.com/ to discover OTP, processes and supervisor and you're ready to code. After learning Erlang, and writing some basic stuff with it, I discovered Elixir and had nothing to learn except: - "defmodule" instead of "package" - "@callback" / "@behaviour" instead of "callback" / "behaviour" - ":an_atom" instead of "an_atom"
anhner 5y ago
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.
- pjmlp 5y ago
  It is easier to get a distributed computing runtime on existing ecosystems than rewriting the world. I have learned Erlang, and like its Prolog inspired syntax, but that is all about it, there is hardly a place for it on the Java/.NET/C++ shops I work on. Akka, Orleans, HPX, OpenMP have much more uptake.
  - atulatul 5y ago
    Just curious about Orleans. I remember reading about it as Erlang inspired MS language. Do you happen to know about adoption in the industry?
    - pjmlp 5y ago
      Orleans is a .NET framework for distributed applications, no language at all. As for industry adoption, it is used by some game studios, for example, http://www.odbms.org/blog/2016/02/orleans-the-technology-behind-xbox-halo4-and-halo5-interview-with-phil-bernstein/ http://www.odbms.org/blog/2016/02/orleans-the-technology-beh... https://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20170209/288516/Creating_scalable_game_backends_in_Microsoft_Orleans_part_1.php https://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20170209/...
- davidw 5y ago
  I had always thought that quote was attributed to Robert Virding: http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...
ramchip 5y ago
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. This article describes it well: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/ http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...
jerf 5y ago
"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.
- derefr 5y ago
  People understand Erlang scaling wrong. Erlang’s distribution model, and its apps like Mnesia, were never designed for horizontal shared-nothing scaling. They were designed for SOA: taking the components or operational roles of a system (e.g. “master” vs “hot standby”) and codifying them into distinct Erlang nodes (which can be developed as separate POSIX processes on the same machine, before being moved to prod to live on separate machines.) People try to scale Erlang systems by trying to get one distribution set to have thousands of nodes; and then taking that thousands-of-nodes cluster, calling that the “master” cluster, and then having another thousands-of-nodes cluster and calling that the “hot standby” cluster. But that’s precisely backwards. Think like Ericsson. You’re designing a switch. You have two independent problems: 1. How do you make your switch Highly Available / fault-tolerant? 2. How do you handle higher load than one switch could possibly handle (for either hardware or software reasons)? To solve problem 1, you create nodes, with roles (e.g. a master and hot standby), where there are an exact number of pre-defined nodes, each with exact static roles. These nodes have defined fault-tolerance relationships. Databases like Mnesia that replicate from one node to another. Applications that have defined chain-of-command such that it’s clear which node becomes the leader if the first leader fails. Etc. You design your system so that some of these nodes can go down, or netsplit, without the system itself going down/crashing. And then you deploy these nodes to separate machines, so that hardware failures will end up being treated the same as node failures. To solve problem 2, you stamp out copies of this entire system of nodes, and add more infrastructure external to it to route between them. In this model, a system of nodes — a distribution-set — is the same type of thing as a Kubernetes Pod. It’s several static processes, one of each role, that inter-depend, and are “wired” to one-another; and then get managed together / treated as one workload. The big difference is that, in contrast to K8s pods that all must get scheduled to one host together, Erlang distribution-sets usually get “scheduled” across several machines. But they still have one identity. They’re a single abstract machine that happens to consist of workloads running on multiple physical machines; where those workloads going down is a designed-for and tolerated aspect of the abstract machine they compose. Everything that happens inside that single abstract machine, is the purview of Erlang and Erlang’s stdlib. Application failover, Mnesia, the thin-client code_server: they’re all designed to make a single abstract machine out of a defined set of Erlang nodes where each node has a static role. Everything that happens outside of the abstract machine, is the purview of user code. Want to horizontally scale the abstract machine? Don’t use the distribution protocol; it’s not tuned for that. Use a userspace library. Have an application that does abstract-machine-to-abstract-machine peering. Make it the role of one or more of your nodes to run that application. Make it fault-tolerant, too. Under this model, I hope you can see that statements like this are mostly incoherent: > 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. ...because an Erlang system architecture that builds one Highly Available abstract machine out of five-to-ten nodes, cannot be swapped out for a system architecture composed of one node, no matter the language it’s written in. The other system, to implement the same fault-tolerance strategies, will need exactly the same number of nodes, because each node performs one or more roles, and serves as a VM-level failure-kernel / bulkhead for HA within those roles. The non-Erlang-implemented system will just have a harder time implementing such strategies, because it’ll mostly have to use userspace libraries/frameworks — rather than VM-level abstractions — to do so. (Though you can get close with languages that have basic syntax that compiles down to framework code in other languages, e.g. if there were a hypothetical “Erleans” that compiled down to C# + .NET Orleans framework calls.) —————— Of course, none of this matters if you don’t have the problem that Erlang solves. If you don’t need a stateful abstract machine that keeps itself online and computing over that state at all costs with fancy multi-node footwork, then you really don’t need any of Erlang’s distribution stuff. But there are still, today, problems that do put you in that position. Stateful packet switching is still a thing. Game servers are another good example. App-layer cache servers (Redis, memcached, etc.) where your architecture couldn’t survive the thundering-herd that would happen if you needed to re-warm the cache from a cold start. Etc. In those contexts, do you really want to try to jury-rig a solution using e.g. Hazelcast + IPVS failover? Better to just use Erlang. Because it’s still ahead of its time, for this problem domain.
davidw 5y ago
> will scale to practically anything Mmmm it's not quite that simple. Erlang requires thought and effort to scale, same as anything.
amw-zero 5y ago
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.

by rapsey 5y ago

jbothma 5y ago

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.

rapsey 5y ago
It does not have that much content in this regard really. https://news.ycombinator.com/item?id=27192873 https://news.ycombinator.com/item?id=27192873
- jbothma 5y ago
  Ah yeah. I'm using python now for the same reason. I don't need more concurrency than a couple of servers with a few web threads and worker threads would give me. PAAS level deployment and failover is sufficient. (Edit: for my needs at the moment) If you keep your async tasks in memory in any system they'll disappear when you deploy. So they weren't really reliant on the things that set erlang apart. So the cost of the small support base in tooling and libraries is more significant.
  - devoutsalsa 5y ago
    Speaking only for myself, I really start to miss the concurrency options in Elixir when I start coding in something else. I start trying to mash concurrency into the other language & dreaming of GenServers & receive functions.
    - jbothma 5y ago
      I miss pattern matching
    - mycall 5y ago
      Have you look at the actor model inside DAPR?
- blackshaw 5y ago
  OP may have also been thinking of this older thread: https://news.ycombinator.com/item?id=23283675 https://news.ycombinator.com/item?id=23283675
AtNightWeCode 5y ago
Akka, Erlang, Service Fabric and so on are based on the Actor Model. You can implement that pattern in any modern language I would say. It is good when it comes to concurrency handling and it can be very simple to understand and to use but async programming is the modern way to solve many of those problems.

lliamander 5y ago

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.

jimsimmons 5y ago
I don’t understand. Which way is simpler?
- lliamander 5y ago
  creating a new service in Erlang.
- radiospiel 5y ago
  "setting up a new service as part of an Erlang release is just an order of magnitude simpler." Maybe this is something to consider: by the use of gen_servers erlang/elixir allows mere developers to build a service, which in the end is just a (lightweight) process managed by OTP (the erlang runtime, so to speak). No ops involved.

silly-silly 5y ago

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.

tommica 5y ago

That is one the reasons why I want to build something with it - it is super exciting!

travisgriggs 5y ago

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?!"

1MachineElf 5y ago
I really felt that story. Mind if I ask, where are you working and what was the Elixir project?
- travisgriggs 5y ago
  The project is ongoing; I work at an automation company :)
truth_ 5y ago
What are the best resources to learn Elixir for a programmer? And what are you using?
- ddek 5y ago
  I liked the book ‘Elixir in Action’. It shows some of the language then immediately jumps into building a way too overcomplicated program (a distributed TODO list) that nicely shows off the features of elixir. After that I just read some codebases. I find elixir codebases extraordinarily easy to read. The language does a great job of making ‘the good way’ also ‘the easy way’, and the linear nature of functional code is much clearer than the usual indirect dependency injected hell. Papercups is a fairly good starting point I think. I liked the livebook codebases too.
- 5y ago

emerongi 5y ago

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.

joelbluminator 5y ago

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).

1_player 5y ago
Last point isn't true. I've been working full time with Elixir for 3 years and I can't write any Erlang. I can read it, just because it's not that complex syntactically. But I should learn Erlang eventually.
- lostcolony 5y ago
  I'll say the high learning curve statement isn't really true for Erlang either. I was up and running with Erlang as a mid level dev back in 2013 or so within 2 weeks. Worked through LYSE, and basically grokked everything I needed to, genservers and OTP included. Only thing tricky after that was building a release (since at the time the best tooling was rebar; Elixir's mix makes this really simple).
- dnautics 5y ago
  same, I can read erlang extremely effectively. Even better than some erlang devs. I can also patch erlang libraries (I fixed my friend's http library to be able to do streaming http 1.1). I can't write it, though.
linkdd 5y ago
Erlang's syntax is so simple I've been able to read the source code of RabbitMQ before even knowing the language. Quickly going through https://learnyousomeerlang.com/ https://learnyousomeerlang.com/ to discover OTP, processes and supervisor and you're ready to code. After learning Erlang, and writing some basic stuff with it, I discovered Elixir and had nothing to learn except: - "defmodule" instead of "package" - "@callback" / "@behaviour" instead of "callback" / "behaviour" - ":an_atom" instead of "an_atom"

anhner 5y ago

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.

pjmlp 5y ago
It is easier to get a distributed computing runtime on existing ecosystems than rewriting the world. I have learned Erlang, and like its Prolog inspired syntax, but that is all about it, there is hardly a place for it on the Java/.NET/C++ shops I work on. Akka, Orleans, HPX, OpenMP have much more uptake.
- atulatul 5y ago
  Just curious about Orleans. I remember reading about it as Erlang inspired MS language. Do you happen to know about adoption in the industry?
  - pjmlp 5y ago
    Orleans is a .NET framework for distributed applications, no language at all. As for industry adoption, it is used by some game studios, for example, http://www.odbms.org/blog/2016/02/orleans-the-technology-behind-xbox-halo4-and-halo5-interview-with-phil-bernstein/ http://www.odbms.org/blog/2016/02/orleans-the-technology-beh... https://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20170209/288516/Creating_scalable_game_backends_in_Microsoft_Orleans_part_1.php https://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20170209/...
davidw 5y ago
I had always thought that quote was attributed to Robert Virding: http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...

ramchip 5y ago

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. This article describes it well: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/ http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...

jerf 5y ago

"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.

derefr 5y ago
People understand Erlang scaling wrong. Erlang’s distribution model, and its apps like Mnesia, were never designed for horizontal shared-nothing scaling. They were designed for SOA: taking the components or operational roles of a system (e.g. “master” vs “hot standby”) and codifying them into distinct Erlang nodes (which can be developed as separate POSIX processes on the same machine, before being moved to prod to live on separate machines.) People try to scale Erlang systems by trying to get one distribution set to have thousands of nodes; and then taking that thousands-of-nodes cluster, calling that the “master” cluster, and then having another thousands-of-nodes cluster and calling that the “hot standby” cluster. But that’s precisely backwards. Think like Ericsson. You’re designing a switch. You have two independent problems: 1. How do you make your switch Highly Available / fault-tolerant? 2. How do you handle higher load than one switch could possibly handle (for either hardware or software reasons)? To solve problem 1, you create nodes, with roles (e.g. a master and hot standby), where there are an exact number of pre-defined nodes, each with exact static roles. These nodes have defined fault-tolerance relationships. Databases like Mnesia that replicate from one node to another. Applications that have defined chain-of-command such that it’s clear which node becomes the leader if the first leader fails. Etc. You design your system so that some of these nodes can go down, or netsplit, without the system itself going down/crashing. And then you deploy these nodes to separate machines, so that hardware failures will end up being treated the same as node failures. To solve problem 2, you stamp out copies of this entire system of nodes, and add more infrastructure external to it to route between them. In this model, a system of nodes — a distribution-set — is the same type of thing as a Kubernetes Pod. It’s several static processes, one of each role, that inter-depend, and are “wired” to one-another; and then get managed together / treated as one workload. The big difference is that, in contrast to K8s pods that all must get scheduled to one host together, Erlang distribution-sets usually get “scheduled” across several machines. But they still have one identity. They’re a single abstract machine that happens to consist of workloads running on multiple physical machines; where those workloads going down is a designed-for and tolerated aspect of the abstract machine they compose. Everything that happens inside that single abstract machine, is the purview of Erlang and Erlang’s stdlib. Application failover, Mnesia, the thin-client code_server: they’re all designed to make a single abstract machine out of a defined set of Erlang nodes where each node has a static role. Everything that happens outside of the abstract machine, is the purview of user code. Want to horizontally scale the abstract machine? Don’t use the distribution protocol; it’s not tuned for that. Use a userspace library. Have an application that does abstract-machine-to-abstract-machine peering. Make it the role of one or more of your nodes to run that application. Make it fault-tolerant, too. Under this model, I hope you can see that statements like this are mostly incoherent: > 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. ...because an Erlang system architecture that builds one Highly Available abstract machine out of five-to-ten nodes, cannot be swapped out for a system architecture composed of one node, no matter the language it’s written in. The other system, to implement the same fault-tolerance strategies, will need exactly the same number of nodes, because each node performs one or more roles, and serves as a VM-level failure-kernel / bulkhead for HA within those roles. The non-Erlang-implemented system will just have a harder time implementing such strategies, because it’ll mostly have to use userspace libraries/frameworks — rather than VM-level abstractions — to do so. (Though you can get close with languages that have basic syntax that compiles down to framework code in other languages, e.g. if there were a hypothetical “Erleans” that compiled down to C# + .NET Orleans framework calls.) —————— Of course, none of this matters if you don’t have the problem that Erlang solves. If you don’t need a stateful abstract machine that keeps itself online and computing over that state at all costs with fancy multi-node footwork, then you really don’t need any of Erlang’s distribution stuff. But there are still, today, problems that do put you in that position. Stateful packet switching is still a thing. Game servers are another good example. App-layer cache servers (Redis, memcached, etc.) where your architecture couldn’t survive the thundering-herd that would happen if you needed to re-warm the cache from a cold start. Etc. In those contexts, do you really want to try to jury-rig a solution using e.g. Hazelcast + IPVS failover? Better to just use Erlang. Because it’s still ahead of its time, for this problem domain.

davidw 5y ago

> will scale to practically anything Mmmm it's not quite that simple. Erlang requires thought and effort to scale, same as anything.

amw-zero 5y ago

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.