5 ms·

Can someone more familiar with Erlang/Elixir say some drawbacks of BEAM? I'm learning Elixir now and as I become more familiar it seems very difficult to write

• Thaxll 9y ago
  Drawbacks, well it's slower than other language ( Java, C#, Go ), it's not typed, the deployment / process liveness mechanisms are now useless with Kubernates / Docker that are better at doing that and language agnostic.
  • bluesnowmonkey 9y ago
    It can be slow, or not. We wrote some serialization code in Elixir and Java, and the Elixir version was a little faster. It's good at that. On the other hand, I had some bit twiddling code that was 13x slower than C. I know because I rewrote that section into C as a NIF and benchmarked. The nice thing then was my overall 95% Elixir app became about as fast as a 100% C app.
    • rurban 9y ago
      Exactly, beam is a pretty slow and unoptimized VM, CPU wise. Which is not so important, as their strength is eliminating IO waits and context switches which are usually much costlier. Their GC is top notch.
  • tabeth 9y ago
    Can you expand on the liveness mechanism bit? Even if K8 could automatically restart containers, I feel without the language itself inherently being able to catch such things, it's not as useful as BEAM processes.
  • yetihehe 9y ago
    Comparing to erlang, docker is pain in the ass. You need to expose one more port to your system? Restart at least one cotainer. Need to link additional containers? Restart at least one. In erlang you just execute some erlang commands and in most cases you don't even drop connections, it's like changing your cylinders in engine when it's still running. Of course if your code has errors it can go wrong, but typically you are only spammed with some errors from this one service until you fix the error and reload code. After you do some code upgrades in erlang, you miss this functionality in all other languages.
• sargun 9y ago
  How would you implement types? receive / send make dealing with types incredibly difficult. Also, hot code reloading makes reasoning about types difficult as well. There's been some proposals for Multi-party session types, but none that are practical by any means.
• hdra 9y ago
  Erlang process are inherently stateful, which makes it hard to fit it into modern deployment infrastructure such as kubernetes that works best with a stateless process. The process model also makes it very tempting to build a monolithic-microservices and build an erlang VM cluster which can add complexity if you already have an infrastructure like kubernetes or works with other languages. FWIW, these things I just mentioned can also be considered as Erlang/Elixir's strengths depending on your requirements.
• mping 9y ago
  It's typed... Dynamically. You mean static types right?
• toast0 9y ago
  When BEAM crashes (which is rare), it turns out your isolated processes aren't isolated. You could mitigate for this by running multiple BEAMs, but that comes at a cost too. BEAM works best if you can model your work as a process, optionally with state, getting messages and sending messages. If that doesn't fit your program, it's not going to be a good fit. There's not a long of bindings into other systems; GUI bindings are problematic -- OTP ships with wxWidgets, but it doesn't feel like Erlang programming to use; I didn't evaluate gtknode, but last commit 2 years ago seems iffy for a project addressing gtk (which I was under the impression changes frequently). If you're dealing with networky things, and the protocol is well documented, it's easy to create your own bindings; it's possible to create your own bindings to other things, but dealing with Erlang data types in C is some amount of effort. Hotloading will warp your mind. For a side project I had written in C, I wanted to hotload the main loop so I didn't need to lose state when I restarted (serializing the state was out of the question because I'm keeping state in a library that doesn't offer serialization); I looked into writing bindings for the interfaces I needed, but it was going to take too much work, so I ended up refactoring my code so I could use dlopen to hot load the main loop in C. :D There are some issues I've run into with OTP, but those aren't really limitations of the BEAM. Lots of OTP doesn't impose explicit limits (or have ways to impose limits), but instead has scaling issues when you hit large numbers / exciting conditions. Most of these _are_ easy to fix, but some of them are frustrating, and are clearly only still broken because there's not a huge community of people, some of which would run into things. For example, the virtual binary heap that was mentioned in the article -- this is a great solution to the problem (the problem is: if you have a simple process that just passes around binaries, it doesn't generate enough garbage on its heap to trigger GC, so the shared binary heap grows rather large), but the fix is pretty recent because not many people ran into it, and when they ran into it, they tended to fix it through manual GC rather than fixing the GC.