5 ms·

static typing (especially HKT), macros, or laziness? The BEAM is amazing, but Erlang is kind of meh. Also the BEAM is very slow so you end up writing C to get a

by smabie 7y ago

static typing (especially HKT), macros, or laziness? The BEAM is amazing, but Erlang is kind of meh. Also the BEAM is very slow so you end up writing C to get any real work done. I haven't used Elixer, but I suspect it suffers from the same problems. When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary.

pdimitar 7y ago
As mentioned in a reply to your sibling comment, the lack of static typing is definitely a minus. Not denying it. Full laziness I found quite overrated while trying to write several very small business services in Haskell. Even in Elixir when you can utilise laziness in limited areas (in the I/O processing stdlibs, but there are almost no data structures for it) it's a proven fact [with benchmarks] that unless your data is at least a list with 500+ elements then laziness introduces both performance penalty and complexity. Not bashing the idea but it's not so universally good as several groups of rather religious programmers seem to make it. Right tool for the right job and all. ;) Macros is Elixir are quite powerful and very different from stuff like it's done in Ruby. They are basically compile-time code generators, utilised with crushing success in Phoenix (web framework), Absinthe (GraphQL) and Ecto (DB data mapper library). Friendly programmer advice: don't underestimate Elixir macros. Many people stayed with Elixir mostly because of them. --- > When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary. 1. Maybe, but I was hearing about preemptive multi-tasking on the JVM when I gave up on Java and that was around 2009. Believe me when I tell you, I really want at least 4-5 other runtimes to gain the capabilities of the BEAM. But alas, they still don't. Only Rust 3rd party runtime devs seem to be truly trying to push the envelope. Everybody else is like "yeah, we're gonna get it done by 2050, no worries". Sorry if that comes across as a bit cynical and dismissive, but I do read history. 2. The preemptive multi-tasking of the BEAM is indeed a huge selling point but not the only one. The actor model -- basically green threads with message inboxes -- are historically being proven more and more as a much more successful parallel computing model compared to... pretty much anything else. Really good Golang devs can kinda-sorta-partially emulate that with channels and mutexes/semaphores but it's obviously manual and error-prone. Rust's `actix` devs also agree and if you look at Techempower's benchmarks that try to emulate real web apps, you'll notice that `actix-web` is on top. Kinda funny when you think about how many people here in HN keep saying the actor model is only a good idea on paper and would never perform well in practice. Additionally, if you keep an eye on the whole ecosystem (as much as that is actually even possible) you'd notice that almost everyone, JS included, is begrudgingly moving to immutable data and lock-less synchronisation. A lot of tech is starting to come to grips with the reality of us humans being flawed and not as bright as we'd like -- me included. I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go, etc. And I can confidently say: it doesn't work sustainably well. You can make a few simple pieces with it but for long-term projects, just go with immutability and lock-less sync. --- I guess my point is, Erlang/Elixir are still quite strong and don't have much serious competition in their niche (where they are doing well). Lastly, I agree that the BEAM in general isn't the fastest thing to run code on. Absolutely. In practice however -- and I mean importing a few million lines of CSV/XML a day -- I found that if you invest just a little more effort, Elixir will stay out of your way and your code will be mostly I/O bound. I mean yeah, Elixir isn't as fast as C++ or Rust. But I already used it for several pretty different projects and it has been performing absolutely excellently. I am looking forward to learn Rust's `actix-web` though. I feel it could be a better fit for some more dramatically more computationally demanding web projects.
- hopia 7y ago
  Actor model is not for parallel computing, it's for concurrency. It introduces unnecessary overhead for parallel computing and is not ideal for it. For concurrency, on the other hand, it's probably superior to anything else out there.
  - pdimitar 7y ago
    Sure. Just saying that the BEAM lends itself to parallelism rather excellently. Conceptually you are correct but in practice -- in the BEAM at least -- those ideas can be converged.
- smabie 7y ago
  You're right, Erlang still has an important feature that (almost?) all other languages lack: preemption. I think the actor model is great, but is crippled if required to use cooperative multi-tasking (like Akka); the code starts simple and then becomes increasingly tangled and complicated. I just think that the Erlang ecosystem has stagnated and the language itself feels dated. If/when the JVM or maybe Rust gets preemption, l think it would be best if all moved on to an actor system built on a more performant, robust, and expressive ecosystem.
  - pdimitar 7y ago
    > If/when the JVM or maybe Rust gets preemption, l think it would be best if all moved on to an actor system built on a more performant, robust, and expressive ecosystem. If Rust gained all BEAM capabilities I'll switch tomorrow, dude. At the moment though, Elixir is just the only choice for excellent parallelism and concurrency. I know Rust is working hard to get there. It's not there yet though.
- FpUser 7y ago
  "...I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go..." Quite frankly most of the multithreading things an synchronization is quite simple and does not bother me except some rare cases (dealing with DirectShow for example). If some languages fail to support real world constructs directly it is the problem of their designers and users. All this stuff about horrible, horrible manual memory management and awful synchronization issues is overblown I think.

by smabie 7y ago

pdimitar 7y ago

As mentioned in a reply to your sibling comment, the lack of static typing is definitely a minus. Not denying it. Full laziness I found quite overrated while trying to write several very small business services in Haskell. Even in Elixir when you can utilise laziness in limited areas (in the I/O processing stdlibs, but there are almost no data structures for it) it's a proven fact [with benchmarks] that unless your data is at least a list with 500+ elements then laziness introduces both performance penalty and complexity. Not bashing the idea but it's not so universally good as several groups of rather religious programmers seem to make it. Right tool for the right job and all. ;) Macros is Elixir are quite powerful and very different from stuff like it's done in Ruby. They are basically compile-time code generators, utilised with crushing success in Phoenix (web framework), Absinthe (GraphQL) and Ecto (DB data mapper library). Friendly programmer advice: don't underestimate Elixir macros. Many people stayed with Elixir mostly because of them. --- > When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary. 1. Maybe, but I was hearing about preemptive multi-tasking on the JVM when I gave up on Java and that was around 2009. Believe me when I tell you, I really want at least 4-5 other runtimes to gain the capabilities of the BEAM. But alas, they still don't. Only Rust 3rd party runtime devs seem to be truly trying to push the envelope. Everybody else is like "yeah, we're gonna get it done by 2050, no worries". Sorry if that comes across as a bit cynical and dismissive, but I do read history. 2. The preemptive multi-tasking of the BEAM is indeed a huge selling point but not the only one. The actor model -- basically green threads with message inboxes -- are historically being proven more and more as a much more successful parallel computing model compared to... pretty much anything else. Really good Golang devs can kinda-sorta-partially emulate that with channels and mutexes/semaphores but it's obviously manual and error-prone. Rust's `actix` devs also agree and if you look at Techempower's benchmarks that try to emulate real web apps, you'll notice that `actix-web` is on top. Kinda funny when you think about how many people here in HN keep saying the actor model is only a good idea on paper and would never perform well in practice. Additionally, if you keep an eye on the whole ecosystem (as much as that is actually even possible) you'd notice that almost everyone, JS included, is begrudgingly moving to immutable data and lock-less synchronisation. A lot of tech is starting to come to grips with the reality of us humans being flawed and not as bright as we'd like -- me included. I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go, etc. And I can confidently say: it doesn't work sustainably well. You can make a few simple pieces with it but for long-term projects, just go with immutability and lock-less sync. --- I guess my point is, Erlang/Elixir are still quite strong and don't have much serious competition in their niche (where they are doing well). Lastly, I agree that the BEAM in general isn't the fastest thing to run code on. Absolutely. In practice however -- and I mean importing a few million lines of CSV/XML a day -- I found that if you invest just a little more effort, Elixir will stay out of your way and your code will be mostly I/O bound. I mean yeah, Elixir isn't as fast as C++ or Rust. But I already used it for several pretty different projects and it has been performing absolutely excellently. I am looking forward to learn Rust's `actix-web` though. I feel it could be a better fit for some more dramatically more computationally demanding web projects.

hopia 7y ago
Actor model is not for parallel computing, it's for concurrency. It introduces unnecessary overhead for parallel computing and is not ideal for it. For concurrency, on the other hand, it's probably superior to anything else out there.
- pdimitar 7y ago
  Sure. Just saying that the BEAM lends itself to parallelism rather excellently. Conceptually you are correct but in practice -- in the BEAM at least -- those ideas can be converged.
smabie 7y ago
You're right, Erlang still has an important feature that (almost?) all other languages lack: preemption. I think the actor model is great, but is crippled if required to use cooperative multi-tasking (like Akka); the code starts simple and then becomes increasingly tangled and complicated. I just think that the Erlang ecosystem has stagnated and the language itself feels dated. If/when the JVM or maybe Rust gets preemption, l think it would be best if all moved on to an actor system built on a more performant, robust, and expressive ecosystem.
- pdimitar 7y ago
  > If/when the JVM or maybe Rust gets preemption, l think it would be best if all moved on to an actor system built on a more performant, robust, and expressive ecosystem. If Rust gained all BEAM capabilities I'll switch tomorrow, dude. At the moment though, Elixir is just the only choice for excellent parallelism and concurrency. I know Rust is working hard to get there. It's not there yet though.
FpUser 7y ago
"...I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go..." Quite frankly most of the multithreading things an synchronization is quite simple and does not bother me except some rare cases (dealing with DirectShow for example). If some languages fail to support real world constructs directly it is the problem of their designers and users. All this stuff about horrible, horrible manual memory management and awful synchronization issues is overblown I think.