5 ms·

Erlang is the future, and the past of concurrency. Any developer worth their salt really should be learning it. If you will take a bit of time to do so, you'll

by nirvana 15y ago

Erlang is the future, and the past of concurrency. Any developer worth their salt really should be learning it. If you will take a bit of time to do so, you'll discover that rather than the incomprehensible scary pain you expect when you first see it, it is quite logical, and quite a joy to work with. In fact, it is a litmus test for me. When I first started looking at NoSQL solutions, I quickly heard of MongoDB. When I found out it was written in C, I suspected that it wouldn't be distributed and it wouldn't be concurrent... and in researching further, those suspicions came true. (by "distributed" I mean, homogeneously like Riak, not the brittle master-server-sharding setup.) Trying to write a truly distributed, concurrent application in C is an exercise in frustration-- you'll have to produce halfway done poor implementation of erlang to do it, or you'll deal with pain every single day. But if you start with erlang, you get these features essentially for free. Plus a couple decades of seriously engineered OTP to go with it. I know a lot of "developers" these days never use anything more .... intense.... than a scripting language. But if you're ready to dive into the deep end, it isn't replicating the experience of writing assembly in C, it is going towards the future-- erlang.

mxavier 15y ago
I'm fairly new when it comes to working with Erlang. We've developed an application we use internally for essentially doing distributed, fault-tolerant timers. I, however, would caution against some of the platitudes you use about it being the future of concurrency. I also think it is kind of silly to imply that a coder isn't "worth their salt" if they aren't learning Erlang. It isn't a panacea. If you read some modern Erlang guides like Learn You Some Erlang, for example, you'll note that a responsible advocate of Erlang will caution against drinking too much kool-aid. Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching. Developers worth their salt will not just hear the word concurrency and start writing everything in Erlang. It is much better to consider the problem and ensure that the problem domain matches Erlang's particular strengths. I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. We actually ended up needing to start a support contract with Erlang Solutions themselves to help us demystify getting a sane deployment process going for our app. This was an expensive endeavor. Yes, it was primarily because we were new to the language, but it also had a lot to do with a lack of community documentation/discussion about deployment procedures. I won't even get into the joy of trying to decipher Erlang's famously cryptic crash reports/stack traces. tl;dr: Erlang isn't concurrency pixie dust. A developer isn't a failure if they aren't currently learning it, nor are they a success if they just decide to use Erlang for every class of problem. It is an interesting language to work with and solves certain problems very well, others not so well.
- luriel 15y ago
  I think Erlang is great, and have been a big fan for a long time, but as you say, it has its limitations and it is nice to have a quite different alternative with Go for concurrent systems. > Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching. This are two areas where Go has a big advantage over Erlang while providing an equivalent (although slightly different and more CSP-ish) concurrency model. > I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. Another big contrasts with Go, where you just build a static binary, copy it to any target systems, and run it.
  - nivertech 15y ago
    Erlang isn't good fit for every concurrent/parallel application, you may read more about it in my answer on Quora: http://www.quora.com/Under-what-conditions-needs-would-Erlang-be-the-most-appropriate-language-to-build-a-product-service http://www.quora.com/Under-what-conditions-needs-would-Erlan... I disagree with Erlang "deployment hell". The full OTP deployment process is too heavy for anything non Telecom or Embedded. But for regular Internet applications, you just creating self-containing tar.gz file with OTP release using "rebar generate". Then you upgrade your cluster in round-robin manner. There are some open-source tools to automate this process. But it's easy to use any Fabric-style tool or just your own bash/ssh scripts.
- nirvana 15y ago
  If you're not using erlang because you don't like its string manipulation capabilities, then you're being foolish. If performance is critical, you can do the string manipulation in C and plug it into erlang fine. If you're trying to do concurrency in most other languages, then you've probably made a foolish decision, unless those languages are also message passing actor model. Claiming that deploying erlang is pure hell is FUD, or an example of how you're doing it wrong and really shouldn't be commenting on erlang.
protomyth 15y ago
Occam was a lot more fun and easier for a C programmer to get. These days, Erlang fits the bill.
meric 15y ago
How does Erlang compare to a theoretical functional programming language that comes with parallel primitives? e.g. fold (+) 0 myArray -- return sum of elements in myArray, in parallel map (*2) myArray -- return a new array with each element in myArray doubled, -- in parallel. You can see that `fold` and `map` abstractions that hides underlying parallel execution. Parallelism is transparent to the programmer. My current belief with regards to the future of concurrent programming: concurrency will be hidden behind abstractions from the programmer to the point that the programmer won't (need) be aware of it; Just as when you are programming ruby & python you are not aware of the underlying assembly instructions that are being executed.[1] Is this what Erlang is like, or, do you still have to deal with race conditions? [1] Haskell Accelerate is an experiment in this direction: https://github.com/mchakravarty/accelerate/blob/master/accelerate-examples/tests/simple/DotP.hs https://github.com/mchakravarty/accelerate/blob/master/accel...
- mononcqc 15y ago
  Erlang isn't exactly about parallelism as much as concurrency. There is a different to both; concurrency is about running independent units of code (at the same time or not) while parallelism has the explicit requirement of things running at the same time. Erlang can be concurrent on a single core, but things can hardly be truly parallel that way. Erlang's parallelism will thus be coming from being able to parallelize concurrent units, something that usually takes place at a higher level than function application for lists and whatnot (although you can use rpc:pmap for your map example). They're not exactly the same. Erlang's concurrency is organisational and explicit; the objective is to delimit subcomponents of a system in well established and isolated units, which can then communicate through message passing. The main objective is not to get things to run faster, but to help manage complexity in large systems.
  - meric 15y ago
    Thanks for the explanation! I understand the difference now.
- gtani 15y ago
  Since it's been a while since I've written any erlang, I'll direct you to pages 112-114 of the (excellent) O'Reilly erlang text by Cesarini and Thompson, which discusses how to deal with race conditions and deadlocks and goes on to say they're extremely rare if you follow standard practices, including mnesia/ETS and OTP behaviors. You have to worry more about mailboxes filling up, and sending large messages between actors, stuff like that.

by nirvana 15y ago

mxavier 15y ago

I'm fairly new when it comes to working with Erlang. We've developed an application we use internally for essentially doing distributed, fault-tolerant timers. I, however, would caution against some of the platitudes you use about it being the future of concurrency. I also think it is kind of silly to imply that a coder isn't "worth their salt" if they aren't learning Erlang. It isn't a panacea. If you read some modern Erlang guides like Learn You Some Erlang, for example, you'll note that a responsible advocate of Erlang will caution against drinking too much kool-aid. Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching. Developers worth their salt will not just hear the word concurrency and start writing everything in Erlang. It is much better to consider the problem and ensure that the problem domain matches Erlang's particular strengths. I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. We actually ended up needing to start a support contract with Erlang Solutions themselves to help us demystify getting a sane deployment process going for our app. This was an expensive endeavor. Yes, it was primarily because we were new to the language, but it also had a lot to do with a lack of community documentation/discussion about deployment procedures. I won't even get into the joy of trying to decipher Erlang's famously cryptic crash reports/stack traces. tl;dr: Erlang isn't concurrency pixie dust. A developer isn't a failure if they aren't currently learning it, nor are they a success if they just decide to use Erlang for every class of problem. It is an interesting language to work with and solves certain problems very well, others not so well.

luriel 15y ago
I think Erlang is great, and have been a big fan for a long time, but as you say, it has its limitations and it is nice to have a quite different alternative with Go for concurrent systems. > Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching. This are two areas where Go has a big advantage over Erlang while providing an equivalent (although slightly different and more CSP-ish) concurrency model. > I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. Another big contrasts with Go, where you just build a static binary, copy it to any target systems, and run it.
- nivertech 15y ago
  Erlang isn't good fit for every concurrent/parallel application, you may read more about it in my answer on Quora: http://www.quora.com/Under-what-conditions-needs-would-Erlang-be-the-most-appropriate-language-to-build-a-product-service http://www.quora.com/Under-what-conditions-needs-would-Erlan... I disagree with Erlang "deployment hell". The full OTP deployment process is too heavy for anything non Telecom or Embedded. But for regular Internet applications, you just creating self-containing tar.gz file with OTP release using "rebar generate". Then you upgrade your cluster in round-robin manner. There are some open-source tools to automate this process. But it's easy to use any Fabric-style tool or just your own bash/ssh scripts.
nirvana 15y ago
If you're not using erlang because you don't like its string manipulation capabilities, then you're being foolish. If performance is critical, you can do the string manipulation in C and plug it into erlang fine. If you're trying to do concurrency in most other languages, then you've probably made a foolish decision, unless those languages are also message passing actor model. Claiming that deploying erlang is pure hell is FUD, or an example of how you're doing it wrong and really shouldn't be commenting on erlang.

protomyth 15y ago

Occam was a lot more fun and easier for a C programmer to get. These days, Erlang fits the bill.

meric 15y ago

How does Erlang compare to a theoretical functional programming language that comes with parallel primitives? e.g. fold (+) 0 myArray -- return sum of elements in myArray, in parallel map (*2) myArray -- return a new array with each element in myArray doubled, -- in parallel. You can see that `fold` and `map` abstractions that hides underlying parallel execution. Parallelism is transparent to the programmer. My current belief with regards to the future of concurrent programming: concurrency will be hidden behind abstractions from the programmer to the point that the programmer won't (need) be aware of it; Just as when you are programming ruby & python you are not aware of the underlying assembly instructions that are being executed.[1] Is this what Erlang is like, or, do you still have to deal with race conditions? [1] Haskell Accelerate is an experiment in this direction: https://github.com/mchakravarty/accelerate/blob/master/accelerate-examples/tests/simple/DotP.hs https://github.com/mchakravarty/accelerate/blob/master/accel...

mononcqc 15y ago
Erlang isn't exactly about parallelism as much as concurrency. There is a different to both; concurrency is about running independent units of code (at the same time or not) while parallelism has the explicit requirement of things running at the same time. Erlang can be concurrent on a single core, but things can hardly be truly parallel that way. Erlang's parallelism will thus be coming from being able to parallelize concurrent units, something that usually takes place at a higher level than function application for lists and whatnot (although you can use rpc:pmap for your map example). They're not exactly the same. Erlang's concurrency is organisational and explicit; the objective is to delimit subcomponents of a system in well established and isolated units, which can then communicate through message passing. The main objective is not to get things to run faster, but to help manage complexity in large systems.
- meric 15y ago
  Thanks for the explanation! I understand the difference now.
gtani 15y ago
Since it's been a while since I've written any erlang, I'll direct you to pages 112-114 of the (excellent) O'Reilly erlang text by Cesarini and Thompson, which discusses how to deal with race conditions and deadlocks and goes on to say they're extremely rare if you follow standard practices, including mnesia/ETS and OTP behaviors. You have to worry more about mailboxes filling up, and sending large messages between actors, stuff like that.