7 ms·

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealin

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release comes with some nice sounding benchmark about how much faster your programs will run in parallel and there is never a mention of whats actually important to programmers, a vibrant ecosystem and community, language improvements that doesnt make it feel like you are programming in the 80's. Better constructs for reusing and packaging code in a sane way. Its fairly trivial in most languages to get the concurrency you need, I think erlang is solving the wrong problem in 2013.

tieTYT 14y ago
I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.
- MichaelGG 14y ago
  What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
  - tieTYT 14y ago
    You mean like the Scala and Clojure libraries? You can use those in Java code if you want.
  - marshray 14y ago
    Erlang itself is, after all, implemented in C and ASM. But what you can't (practically) implement yourself in other languages is all the professional care and maturity that have gone into the whole package over its long history. AFAICT, Erlang/OTP is much more than just a library.
  - sshumaker 14y ago
    Ultra-lightweight actors, a VM scheduler tuned for scheduling massive numbers of concurrent ops, etc. If you tried doing this in with a java library running java code, you couldn't get anywhere near their level of concurrency.
  - Evbn 14y ago
    Java's syntactic overhead stops most humans. "final" everywhere, big method names for every primitive message passing operation, etc
  - SoftwareMaven 14y ago
    How would you get per-actor heaps that cannot be violated by other actors? That is critical to Erlang's ability to recover from processes dying. I spent a lot of time doing Java and can't think how you could (you could in the JVM if you had language constructs for it, but then we are back to a new language). There's a reason Stackless Python's actors aren't just a library on top of Python.
    - reeses 14y ago
      TLABs are a partial step in that direction at the JVM level. You could also use object pools/factories keyed to the thread. Those are the first two "ghetto" hack solutions I can think of that wouldn't require significant code changes on a going-forward basis.
      - SoftwareMaven 14y ago
        But those hacks wouldn't provide the same guarantees that language-level changes provide. Sure, you can try not to impact other thread's heaps, but nothing is stopping me, which means a simple programming error has the potential to impact multiple threads. As a result, you can't just "reboot" that thread (a critical piece of what makes Erlang interesting), because you have no guarantees its errors didn't impact other threads. You also have no guarantees that the underlying libraries aren't mucking up all of your carefully crafted memory management. It's like the kernel protecting memory so applications can't overwrite each other. Sure, applications could just write to their own memory, but nobody actually trusts that model[1]. Instead, they want something below that level enforcing good behavior. 1. Obviously, virtual memory adds a wrinkle to this that kind of forces kernel protection, but even if we had literally unlimited RAM, we would still implement kernel protections on memory.
        reeses 14y ago
        Unfortunately, with any native code interaction, whether explicit FFI/NIF or implicit (RNG, clock, etc.), your threads can still mingle state. In a single process, you're still limited by the memory virtualization capabilities of your underlying processor and MMU.
  - dumael 14y ago
    You can at best implement a mimicry of Erlang's message passing in Java. With sufficient effort, you can have the equivalent of no shared mutable data. What you cannot have is completely separate heaps, so that if one thread crashes for whatever reason it doesn't take your application down. Also, good luck trying to find a garbage collector that supports completely separate heaps that isn't a direct copy/near-identical implementation of the BEAM[1] VM's GC. [1] The virtual machine that is the stock VM for Erlang. (In fact I don't know of any others but I have never looked.)
    - reeses 14y ago
      We've been doing it in Java since the nasty old days of RMI or "our own weird RPC over HTTP implementation". Lots of lightweight services with a supervisor to manage them and a directory to find them. Now it's even easier with ESBs. Write a ten-line grails service to expose a bin-packing facility with Drools and then never touch it again.
  - reeses 14y ago
    Obviously, you can do the same things in Java, as people have demonstrated with alternative languages that target the JVM. It's the expressiveness at the language level that is really the "magic". For example, doing the equivalent of OO is not intuitive in Erlang, but completely possible (actually easy, but it looks...wrong) whereas it's supported by every Java tool. By the same token, pattern-matched message passing, lightweight green threads, and hot code deployment are primary concepts in Erlang.
- digitalzombie 14y ago
  http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-... It's also preemptive too. I don't believe JVM have this nor any other languages.
masklinn 14y ago
> I havent tried go or dart yet Well Go uses shared-memory concurrency and no other so... Rust still looks more interesting there, though they still have to deliver the language (it's still heavily in flux)
- kkowalczyk 14y ago
  Go allows you to share memory between goroutines (i.e. concurrent code). It doesn't force you to do so. In fact, the Go team explicitly tells you not to do that: "do not communicate by sharing memory; instead, share memory by communicating." (http://blog.golang.org/2010/07/share-memory-by-communicating.html http://blog.golang.org/2010/07/share-memory-by-communicating...) i.e. they tell you to use the Erlang model. But as everything, there are trade-offs. Even Go team uses shared memory protected by locks in some cases (see Go standard library) because it's faster or easier that way. Every good idea (sharing memory between threads is dangerous and therefore should be avoided) taken to extreme becomes cargo cult programming. Yes, it is dangerous, but at the same time there are plenty of successful projects that do it because there are programmers that can contain that complexity despite the somewhat popular view that this approach dooms you to failure.
  - masklinn 14y ago
    > Go allows you to share memory between goroutines (i.e. concurrent code). Go will share memory, by default, and special attention must be taken preventing or avoiding it. It's not an allowance. > In fact, the Go team explicitly tells you not to do that And yet they have refused to implement a correct model, even though they have no problem imposing their view when it fits them (and having the interpreter get special status in breaking them, see generics).
    - burntsushi 14y ago
      > Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go with the same kind of concurrency model used in C. > And yet they have refused to implement a correct model What is a correct model? Erlang's model isn't correct. It's just more safe. > (and having the interpreter get special status in breaking them, see generics) What's your point? Purity for purity's sake?
rdtsc 14y ago
> However it has barely evolved in the last 10 years, will 2013 be the year of the structs? Eh... It is not perfect but considering everything else it brings to the table (fault tolerance, distribution, concurrency) I can easily overlook its warts. There is always Elixir or some LISP like dialects running on the BEAM VM as an alternative. I for one like its syntax. It makes sense to me somehow. I which maps were there and I think one day they will be. I would rather they'd work on concurrency, speed and distribution.
- daleharvey 14y ago
  The syntax is a fairly minor point, and although its ridiculous there isnt first class dictionary support in 2013 there are parts of it I really like. But Ericcson dont know how to manage an open source ecosystem, I dont think they particularly want to. It only started using an open source control a few years ago, still no open bug tracker, half the standard library is in terrible shape, there is no good support for 3rd party library integration. A few years ago I wrote a UI to the documentation that most of the community seemed to massively prefer (http://erldocs.com http://erldocs.com). Every year I asked the OTP manager how to get it merged but instead they wrote their own (imo) sub par version while every release changing the documentation format which broke mine without warning.

tieTYT 14y ago

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

MichaelGG 14y ago
What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
- tieTYT 14y ago
  You mean like the Scala and Clojure libraries? You can use those in Java code if you want.
- marshray 14y ago
  Erlang itself is, after all, implemented in C and ASM. But what you can't (practically) implement yourself in other languages is all the professional care and maturity that have gone into the whole package over its long history. AFAICT, Erlang/OTP is much more than just a library.
- sshumaker 14y ago
  Ultra-lightweight actors, a VM scheduler tuned for scheduling massive numbers of concurrent ops, etc. If you tried doing this in with a java library running java code, you couldn't get anywhere near their level of concurrency.
- Evbn 14y ago
  Java's syntactic overhead stops most humans. "final" everywhere, big method names for every primitive message passing operation, etc
- SoftwareMaven 14y ago
  How would you get per-actor heaps that cannot be violated by other actors? That is critical to Erlang's ability to recover from processes dying. I spent a lot of time doing Java and can't think how you could (you could in the JVM if you had language constructs for it, but then we are back to a new language). There's a reason Stackless Python's actors aren't just a library on top of Python.
  - reeses 14y ago
    TLABs are a partial step in that direction at the JVM level. You could also use object pools/factories keyed to the thread. Those are the first two "ghetto" hack solutions I can think of that wouldn't require significant code changes on a going-forward basis.
    - SoftwareMaven 14y ago
      But those hacks wouldn't provide the same guarantees that language-level changes provide. Sure, you can try not to impact other thread's heaps, but nothing is stopping me, which means a simple programming error has the potential to impact multiple threads. As a result, you can't just "reboot" that thread (a critical piece of what makes Erlang interesting), because you have no guarantees its errors didn't impact other threads. You also have no guarantees that the underlying libraries aren't mucking up all of your carefully crafted memory management. It's like the kernel protecting memory so applications can't overwrite each other. Sure, applications could just write to their own memory, but nobody actually trusts that model[1]. Instead, they want something below that level enforcing good behavior. 1. Obviously, virtual memory adds a wrinkle to this that kind of forces kernel protection, but even if we had literally unlimited RAM, we would still implement kernel protections on memory.
      - reeses 14y ago
        Unfortunately, with any native code interaction, whether explicit FFI/NIF or implicit (RNG, clock, etc.), your threads can still mingle state. In a single process, you're still limited by the memory virtualization capabilities of your underlying processor and MMU.
- dumael 14y ago
  You can at best implement a mimicry of Erlang's message passing in Java. With sufficient effort, you can have the equivalent of no shared mutable data. What you cannot have is completely separate heaps, so that if one thread crashes for whatever reason it doesn't take your application down. Also, good luck trying to find a garbage collector that supports completely separate heaps that isn't a direct copy/near-identical implementation of the BEAM[1] VM's GC. [1] The virtual machine that is the stock VM for Erlang. (In fact I don't know of any others but I have never looked.)
  - reeses 14y ago
    We've been doing it in Java since the nasty old days of RMI or "our own weird RPC over HTTP implementation". Lots of lightweight services with a supervisor to manage them and a directory to find them. Now it's even easier with ESBs. Write a ten-line grails service to expose a bin-packing facility with Drools and then never touch it again.
- reeses 14y ago
  Obviously, you can do the same things in Java, as people have demonstrated with alternative languages that target the JVM. It's the expressiveness at the language level that is really the "magic". For example, doing the equivalent of OO is not intuitive in Erlang, but completely possible (actually easy, but it looks...wrong) whereas it's supported by every Java tool. By the same token, pattern-matched message passing, lightweight green threads, and hot code deployment are primary concepts in Erlang.
digitalzombie 14y ago
http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-... It's also preemptive too. I don't believe JVM have this nor any other languages.

masklinn 14y ago

> I havent tried go or dart yet Well Go uses shared-memory concurrency and no other so... Rust still looks more interesting there, though they still have to deliver the language (it's still heavily in flux)

kkowalczyk 14y ago
Go allows you to share memory between goroutines (i.e. concurrent code). It doesn't force you to do so. In fact, the Go team explicitly tells you not to do that: "do not communicate by sharing memory; instead, share memory by communicating." (http://blog.golang.org/2010/07/share-memory-by-communicating.html http://blog.golang.org/2010/07/share-memory-by-communicating...) i.e. they tell you to use the Erlang model. But as everything, there are trade-offs. Even Go team uses shared memory protected by locks in some cases (see Go standard library) because it's faster or easier that way. Every good idea (sharing memory between threads is dangerous and therefore should be avoided) taken to extreme becomes cargo cult programming. Yes, it is dangerous, but at the same time there are plenty of successful projects that do it because there are programmers that can contain that complexity despite the somewhat popular view that this approach dooms you to failure.
- masklinn 14y ago
  > Go allows you to share memory between goroutines (i.e. concurrent code). Go will share memory, by default, and special attention must be taken preventing or avoiding it. It's not an allowance. > In fact, the Go team explicitly tells you not to do that And yet they have refused to implement a correct model, even though they have no problem imposing their view when it fits them (and having the interpreter get special status in breaking them, see generics).
  - burntsushi 14y ago
    > Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go with the same kind of concurrency model used in C. > And yet they have refused to implement a correct model What is a correct model? Erlang's model isn't correct. It's just more safe. > (and having the interpreter get special status in breaking them, see generics) What's your point? Purity for purity's sake?

rdtsc 14y ago

> However it has barely evolved in the last 10 years, will 2013 be the year of the structs? Eh... It is not perfect but considering everything else it brings to the table (fault tolerance, distribution, concurrency) I can easily overlook its warts. There is always Elixir or some LISP like dialects running on the BEAM VM as an alternative. I for one like its syntax. It makes sense to me somehow. I which maps were there and I think one day they will be. I would rather they'd work on concurrency, speed and distribution.

daleharvey 14y ago
The syntax is a fairly minor point, and although its ridiculous there isnt first class dictionary support in 2013 there are parts of it I really like. But Ericcson dont know how to manage an open source ecosystem, I dont think they particularly want to. It only started using an open source control a few years ago, still no open bug tracker, half the standard library is in terrible shape, there is no good support for 3rd party library integration. A few years ago I wrote a UI to the documentation that most of the community seemed to massively prefer (http://erldocs.com http://erldocs.com). Every year I asked the OTP manager how to get it merged but instead they wrote their own (imo) sub par version while every release changing the documentation format which broke mine without warning.