6 ms·

When would you choose Erlang? (2013)

109 points by rubyn00bie 11y ago

MCRed 11y ago
When you want to scale across multiple servers without much effort.
- devbug 11y ago
  Multiple. Scaling to a multitude takes a lot of effort.
  - lectrick 11y ago
    Are there any tools to help with "multitude"-level scaling? It's been my experience (across all langs) that every new order of magnitude of scaling requires a new technology/technique/architecture...
    - deleted 11y ago
      [deleted]
    - devbug 11y ago
      Not to my knowledge, no. Sorry.
      - lectrick 11y ago
        So folks like WhatsApp basically do homegrown solutions?
- supercoder 11y ago
  Well except for the effort of building your entire app on Erlang.
vezzy-fnord 11y ago
I actually enjoy the language itself. Functional, but not tacit. The module system provides good namespacing boundaries and package encapsulation. A data type-driven programming style emphasizing pattern matching on primal terms like tuples and lists. Good syntax for list comprehensions. On and on. I would switch to Elixir, but the syntax is too weird.
- digitalzombie 11y ago
  The list comprehension syntax gets confusing for me to read especially with pattern matching.
  - seiji 11y ago
    Haskell: https://gist.github.com/gigamonkey/6249d85021bc8bf54eb4 https://gist.github.com/gigamonkey/6249d85021bc8bf54eb4 Erlang: https://gist.github.com/mattsta/b6749e566f5cfd75762a https://gist.github.com/mattsta/b6749e566f5cfd75762a List comprehensions make no sense to anybody at first. But after you work with and struggle against them for a few days/weeks, everything will click. You'll be a better developer for understand them more intuitively.
    - EarthLaunch 11y ago
      I don't know about that last part. I spent years with Erlang until finally list comprehensions became natural, and I still don't feel like a better programmer!
- lectrick 11y ago
  > but the syntax is too weird Ah, I've finally found someone in the wild who thinks Erlang's syntax is less weird than Elixir's! ;)
  - bliti 11y ago
    It is weird. I do question their choice for ruby like syntax. Still is a fine language. It just gets confusing because a language is made up of its idioms and syntax. If you copy those a then you confuse people.
nextos 11y ago
It's really really enlightening to see how you can build Erlang as a Prolog DSL. Since Prolog is homoiconic, it's quite easy: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD9019868EB657DD1BCEB3900849D82?doi=10.1.1.34.3972&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD... That's actually how Erlang was born, hence the apparently odd syntax.
ffn 11y ago
>Erlang is not good for Glue-together style web application Granted Elixir's Phoenix framework is not Rails level yet, it's system of plugs and heavy inspiration from rails actually makes it quite useable as a replacement for rails. Also immutability and the associated smaller memory footprint makes it more feasible to run cheaply on services like heroku or aws. Personally, I think elixir is a good boat to jump on to carry us over to the next world of web development.
- troutwine 11y ago
  I wrote this article way back in 2013. Initial commit of Phoenix was Jan 18, 2014. But! you're quite right. Elixir is focusing on the web application type things that Erlang and the community around it has never much addressed. There's enough interoperability from Elixir to Erlang that you could probably say the ecosystem as a whole is addressing the problem if you squint hard enough. Side comment, it's been interesting to see Elixir grow since 2013. A lot of folks learn Elixir and then Erlang but I think it's less common to learn Erlang and then learn Elixir. It's led to an interesting situation where Elixir has had to bootstrap knowledge about OTP on its own terms without a large pool of domain experts sitting around. The asymmetry in knowledge--knowing Erlang does not imply knowing Elixir but knowing Elixir implies knowing Erlang--also makes me wonder how the squinting assumption above will shake out long-term. ¯\_(シ)_/¯
  - eggy 11y ago
    I have played with Elixir, and it is certainly gaining in popularity I believe due to its rubiness and web dev. Personally, I prefer LFE, but that's because I am a Lisper and love parentheses. I am reading 'The Handbook of Neuroevolution through Erlang'. It is a great use for Erlang. I am hoping somebody will work on the LFE translation of it. Good article.
  - phamilton 11y ago
    As someone who has gone from Ruby -> Erlang -> Elixir, I'm both thrilled and terrified by the culture developing. On one hand, you have a very similar open source culture to what exists in Ruby. The fact that hex.pm exists alone is amazing. Libraries are expected to work, be documented, and be maintained. On the other hand, the number of questions that can be answered with RTFM is astoundingly high. Where Erlang has an implicit knowledge requirement regarding OTP and distributed systems in general, Elixir has a much lower barrier to entry in the community. An Example: On one of my libraries (a db driver) I have received multiple requests for "Add section to README on how to use this with Phoenix". I have a section on how to add to a supervision tree, which from the erlang world is overkill, and I expect users to be able to connect the dots. That said, the core team is pretty dang smart. There's plenty of OTP wisdom there, and they aren't very quick to give into the mob rule of the community. It's under strong guidance.
bsder 11y ago
Choose Erlang when your single most important characteristic is uptime. Erlang is excellent for problems where latency is an issue. It's really good for problems where scaling is an issue. But uptime is the big one. The whole immutable, recursive calls, and kill-and-restart quickly is a very good architecture for when you need all those nines.
- MichaelGG 11y ago
  Can you elaborate on kill and restart? I feel I must be missing something. How is restarting processes different than wrapping workers in a try/catch, or just restarting OS processes? More interestingly, how does this help uptime? I've been in telephony for a while. My software related downtime (vs human error breaking things) seem either related to logic bugs (restarting won't help) or load (simply too little hardware for a, say, 100x increase in traffic). Maybe Erlang's selling points make more sense compared to C instead of a managed language? For instance I often hear about the robustness of the Erlang VM, yet JVM or CLR integrity has never been an issue for me.
  - vezzy-fnord 11y ago
    It's quite different in the context of Erlang, so you should probably research that yourself to get the right impression. Restarting does help with logic bugs depending on what execution path triggers it. Bringing back a process to a known good state is a heavily useful concession to keep services up and doing work until the root cause is diagnosed and fixed.
  - bsder 11y ago
    The other comment here recommending that you research it yourself is spot on. Nevertheless, I'll try. In Erlang, almost everything is immutable. So, if you want to update state, you build a new state, and then call yourself recursively with the new state. Seems annoying, right? Except, I can invert this where I keep the state the same but vary the code. If I want to update my code, I can tell the old code to pack up it's old state and call my new code recursively. No downtime. At all. Robustness: the Erlang VM keeps track of a cost for just about everything in its preemptive scheduler. The scheduler is tuned for latency rather than throughput. So, when you get 100X increase in traffic, the scheduler continues to make progress even if it's resource is getting overloaded. In addition GC pauses are per scheduler/process rather than global. This is a function of the fact that Erlang tends to serialize nearly everything so it doesn't have to share. As for kill/restart, these things tend to be an architectural idiom that is shared by the standard library rather than an obscure technique that only a handful of the programmers grasp. Kill/restart is expected to be NORMAL in Erlang and is thus fast with low overhead--try/catch tends to be abnormal and restarting OS processes tends to be slow. There are a lot of good things wrapped into Erlang. If you've just used imperative C variant languages (C, Java, C#, Python, Ruby, etc.), I recommend using it in a bit of anger. It can be frustrating until you get your head wrapped around it, but I still retain the architectural elements when I write certain tasks in other languages.
FullyFunctional 11y ago
I've known and loved Haskell for more than a decade so when I was "encouraged" to learn Erlang it expected to hate it. I was thoroughly surprised to see how nice it is. As for the syntax, I mostly find it great (but obviously different). Something I find worth emphasizing: There is exactly one integer type and integers are unbounded. Very few languages gets this right and it's IMO one of the worst mistakes in Haskell. This takes care of a whole slew of bugs and security pitfalls. I'm still an Erlang n00b, but the lack of a native string type seems a major weakness -- strings are isomorphic to a list of small integers, worse than even Haskell. Please give us something based on Ropes, like in Cedar (http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/abstract http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/ab...). EDIT: typo.
- Ixiaus 11y ago
  Haskeller here too. We rely on it [Erlang] for a mission-critical program that runs in an embedded linux environment; we use every touted feature of Erlang/OTP too. While I do miss typeclasses, applicatives, strong and static typing, the Reader monad, lens, Attoparsec, and many other wonderful Haskell experiences -- I can safely say that there is currently no mature and cohesive analog of Erlang's best features in Haskell. - Easy cross-compilation. - Out-of-the-box distributed RPC and inter-node connections. Extremely important for our product. - Supervisor trees (the bees-knees of Erlang). - Isolation of specific functionality into OTP applications with their own supervision hierarchies (some bound to specific "events", like an AMQP Client coming up upon successful WiFi AP association) - this also protects us from the dreaded "xyz had a bug in it and took down the whole program, it's now bricked". - Hot code loading and release management. This one is particularly awesome. The node itself is told to upgrade via AMQP, it fetches the latest Release, unpacks it, and rebuilds the engine while driving. There are quite a few built-in safe-guards and checks too until you reach the point of no return in the upgrade. Release management is amazing in Erlang, I have yet to see anything like this in any of the languages I've ever used. - A proliferation of distributed consensus libraries and utilities thanks to Basho. We use plumtree for replicating the state of each node across its cluster within the user's home. Lots of cool features are possible because of this simple but extremely difficult to get right software. - The dialyzer isn't anywhere near Haskell's type system but it does give us some useful information and checks.

109 points by rubyn00bie 11y ago

MCRed 11y ago

When you want to scale across multiple servers without much effort.

devbug 11y ago
Multiple. Scaling to a multitude takes a lot of effort.
- lectrick 11y ago
  Are there any tools to help with "multitude"-level scaling? It's been my experience (across all langs) that every new order of magnitude of scaling requires a new technology/technique/architecture...
  - deleted 11y ago
    [deleted]
  - devbug 11y ago
    Not to my knowledge, no. Sorry.
    - lectrick 11y ago
      So folks like WhatsApp basically do homegrown solutions?
supercoder 11y ago
Well except for the effort of building your entire app on Erlang.

vezzy-fnord 11y ago

I actually enjoy the language itself. Functional, but not tacit. The module system provides good namespacing boundaries and package encapsulation. A data type-driven programming style emphasizing pattern matching on primal terms like tuples and lists. Good syntax for list comprehensions. On and on. I would switch to Elixir, but the syntax is too weird.

digitalzombie 11y ago
The list comprehension syntax gets confusing for me to read especially with pattern matching.
- seiji 11y ago
  Haskell: https://gist.github.com/gigamonkey/6249d85021bc8bf54eb4 https://gist.github.com/gigamonkey/6249d85021bc8bf54eb4 Erlang: https://gist.github.com/mattsta/b6749e566f5cfd75762a https://gist.github.com/mattsta/b6749e566f5cfd75762a List comprehensions make no sense to anybody at first. But after you work with and struggle against them for a few days/weeks, everything will click. You'll be a better developer for understand them more intuitively.
  - EarthLaunch 11y ago
    I don't know about that last part. I spent years with Erlang until finally list comprehensions became natural, and I still don't feel like a better programmer!
lectrick 11y ago
> but the syntax is too weird Ah, I've finally found someone in the wild who thinks Erlang's syntax is less weird than Elixir's! ;)
- bliti 11y ago
  It is weird. I do question their choice for ruby like syntax. Still is a fine language. It just gets confusing because a language is made up of its idioms and syntax. If you copy those a then you confuse people.

nextos 11y ago

It's really really enlightening to see how you can build Erlang as a Prolog DSL. Since Prolog is homoiconic, it's quite easy: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD9019868EB657DD1BCEB3900849D82?doi=10.1.1.34.3972&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD... That's actually how Erlang was born, hence the apparently odd syntax.

ffn 11y ago

>Erlang is not good for Glue-together style web application Granted Elixir's Phoenix framework is not Rails level yet, it's system of plugs and heavy inspiration from rails actually makes it quite useable as a replacement for rails. Also immutability and the associated smaller memory footprint makes it more feasible to run cheaply on services like heroku or aws. Personally, I think elixir is a good boat to jump on to carry us over to the next world of web development.

troutwine 11y ago
I wrote this article way back in 2013. Initial commit of Phoenix was Jan 18, 2014. But! you're quite right. Elixir is focusing on the web application type things that Erlang and the community around it has never much addressed. There's enough interoperability from Elixir to Erlang that you could probably say the ecosystem as a whole is addressing the problem if you squint hard enough. Side comment, it's been interesting to see Elixir grow since 2013. A lot of folks learn Elixir and then Erlang but I think it's less common to learn Erlang and then learn Elixir. It's led to an interesting situation where Elixir has had to bootstrap knowledge about OTP on its own terms without a large pool of domain experts sitting around. The asymmetry in knowledge--knowing Erlang does not imply knowing Elixir but knowing Elixir implies knowing Erlang--also makes me wonder how the squinting assumption above will shake out long-term. ¯\_(シ)_/¯
- eggy 11y ago
  I have played with Elixir, and it is certainly gaining in popularity I believe due to its rubiness and web dev. Personally, I prefer LFE, but that's because I am a Lisper and love parentheses. I am reading 'The Handbook of Neuroevolution through Erlang'. It is a great use for Erlang. I am hoping somebody will work on the LFE translation of it. Good article.
- phamilton 11y ago
  As someone who has gone from Ruby -> Erlang -> Elixir, I'm both thrilled and terrified by the culture developing. On one hand, you have a very similar open source culture to what exists in Ruby. The fact that hex.pm exists alone is amazing. Libraries are expected to work, be documented, and be maintained. On the other hand, the number of questions that can be answered with RTFM is astoundingly high. Where Erlang has an implicit knowledge requirement regarding OTP and distributed systems in general, Elixir has a much lower barrier to entry in the community. An Example: On one of my libraries (a db driver) I have received multiple requests for "Add section to README on how to use this with Phoenix". I have a section on how to add to a supervision tree, which from the erlang world is overkill, and I expect users to be able to connect the dots. That said, the core team is pretty dang smart. There's plenty of OTP wisdom there, and they aren't very quick to give into the mob rule of the community. It's under strong guidance.

bsder 11y ago

Choose Erlang when your single most important characteristic is uptime. Erlang is excellent for problems where latency is an issue. It's really good for problems where scaling is an issue. But uptime is the big one. The whole immutable, recursive calls, and kill-and-restart quickly is a very good architecture for when you need all those nines.

MichaelGG 11y ago
Can you elaborate on kill and restart? I feel I must be missing something. How is restarting processes different than wrapping workers in a try/catch, or just restarting OS processes? More interestingly, how does this help uptime? I've been in telephony for a while. My software related downtime (vs human error breaking things) seem either related to logic bugs (restarting won't help) or load (simply too little hardware for a, say, 100x increase in traffic). Maybe Erlang's selling points make more sense compared to C instead of a managed language? For instance I often hear about the robustness of the Erlang VM, yet JVM or CLR integrity has never been an issue for me.
- vezzy-fnord 11y ago
  It's quite different in the context of Erlang, so you should probably research that yourself to get the right impression. Restarting does help with logic bugs depending on what execution path triggers it. Bringing back a process to a known good state is a heavily useful concession to keep services up and doing work until the root cause is diagnosed and fixed.
- bsder 11y ago
  The other comment here recommending that you research it yourself is spot on. Nevertheless, I'll try. In Erlang, almost everything is immutable. So, if you want to update state, you build a new state, and then call yourself recursively with the new state. Seems annoying, right? Except, I can invert this where I keep the state the same but vary the code. If I want to update my code, I can tell the old code to pack up it's old state and call my new code recursively. No downtime. At all. Robustness: the Erlang VM keeps track of a cost for just about everything in its preemptive scheduler. The scheduler is tuned for latency rather than throughput. So, when you get 100X increase in traffic, the scheduler continues to make progress even if it's resource is getting overloaded. In addition GC pauses are per scheduler/process rather than global. This is a function of the fact that Erlang tends to serialize nearly everything so it doesn't have to share. As for kill/restart, these things tend to be an architectural idiom that is shared by the standard library rather than an obscure technique that only a handful of the programmers grasp. Kill/restart is expected to be NORMAL in Erlang and is thus fast with low overhead--try/catch tends to be abnormal and restarting OS processes tends to be slow. There are a lot of good things wrapped into Erlang. If you've just used imperative C variant languages (C, Java, C#, Python, Ruby, etc.), I recommend using it in a bit of anger. It can be frustrating until you get your head wrapped around it, but I still retain the architectural elements when I write certain tasks in other languages.

FullyFunctional 11y ago

I've known and loved Haskell for more than a decade so when I was "encouraged" to learn Erlang it expected to hate it. I was thoroughly surprised to see how nice it is. As for the syntax, I mostly find it great (but obviously different). Something I find worth emphasizing: There is exactly one integer type and integers are unbounded. Very few languages gets this right and it's IMO one of the worst mistakes in Haskell. This takes care of a whole slew of bugs and security pitfalls. I'm still an Erlang n00b, but the lack of a native string type seems a major weakness -- strings are isomorphic to a list of small integers, worse than even Haskell. Please give us something based on Ropes, like in Cedar (http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/abstract http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/ab...). EDIT: typo.

Ixiaus 11y ago
Haskeller here too. We rely on it [Erlang] for a mission-critical program that runs in an embedded linux environment; we use every touted feature of Erlang/OTP too. While I do miss typeclasses, applicatives, strong and static typing, the Reader monad, lens, Attoparsec, and many other wonderful Haskell experiences -- I can safely say that there is currently no mature and cohesive analog of Erlang's best features in Haskell. - Easy cross-compilation. - Out-of-the-box distributed RPC and inter-node connections. Extremely important for our product. - Supervisor trees (the bees-knees of Erlang). - Isolation of specific functionality into OTP applications with their own supervision hierarchies (some bound to specific "events", like an AMQP Client coming up upon successful WiFi AP association) - this also protects us from the dreaded "xyz had a bug in it and took down the whole program, it's now bricked". - Hot code loading and release management. This one is particularly awesome. The node itself is told to upgrade via AMQP, it fetches the latest Release, unpacks it, and rebuilds the engine while driving. There are quite a few built-in safe-guards and checks too until you reach the point of no return in the upgrade. Release management is amazing in Erlang, I have yet to see anything like this in any of the languages I've ever used. - A proliferation of distributed consensus libraries and utilities thanks to Basho. We use plumtree for replicating the state of each node across its cluster within the user's home. Lots of cool features are possible because of this simple but extremely difficult to get right software. - The dialyzer isn't anywhere near Haskell's type system but it does give us some useful information and checks.