3 ms·

I'm personally still waiting for the JIT. I guess it will be a while.

alberth 8y ago
+1000 I couldn't agree more. I have a lot of hope for BEAMJIT (or anything that will make Erlang faster per clock cycle). http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/ After reading the link above, I get the sad feeling that a faster Erlang isn't anytime soon :( With that being sad, Elixir has brought a whole new wave of people to the OTP community. Which excites me tremendously. I just hope a faster Erlang will arrive soon enough so that people needing to leave Ruby due to slowness have a good alternative with Erlang.
- klibertp 8y ago
  According to this talk: https://www.youtube.com/watch?v=PtgD5WRzcy4 https://www.youtube.com/watch?v=PtgD5WRzcy4 there is some (initial and under development as I understand) implementation already, with results generally 50% worse than HiPE. It looks better than any previous attempt, so maybe it's time to get a little optimistic :) Also, while additional performance never hurts, the slowness in the Erlang case is really a different kind of a problem than it is in Python or Ruby. Erlang's performance requirements are closer to those of BASH and other shells: there is no need, and no expectation, to have all the code in Erlang. The variety of options for integrating other languages should make this obvious. Even if in general Erlang is rather unimpressive in terms of performance (I'm trying to be diplomatic here...), it does have a couple of highly optimized parts, like the IO, context switching or message passing - in other words, the optimizations are focused on the things that make Erlang special and that other languages generally don't focus on. It makes Erlang often "worth it" even despite the slowness, and it works well in practice, in my experience. Elixir makes it a bit more awkward. On the one hand, it's a nice language, which is general-purpose enough to look reasonable as an implementation language for most anything. On the other, no matter the amount of pre-computations and clever macrology, it shares the same fundamental limitations that Erlang has - like a lot of copies of everything or non-inlineable calls due to how modules are made reloadable - and it's going to lead to a lot of frustration and emotional rants from people who actually tried to use it as a "reasonable, general-purpose" language without the required preparations. Even when the JIT arrives, it's not going to fit all the performance profiles equally, and the need to carefully consider the performance you need won't disappear.
  - plainOldText 8y ago
    Yes, there will always be certain limitations as you've accurately mentioned. However, as a platform for writing networked web services, I think the Erlang VM is stellar. Compared to other languages, such as Go, Python, Rust, etc, the conceptual models in Erlang (processes, message passing, supervision trees) and how they all work, map better to the web problem domain. As far as the slow parts, like you said, there are plenty of choices of integrating other languages.
- plainOldText 8y ago
  I've never been as happy programming in a language as I've been in Elixir and its ecosystem. A complete joy! So yeah, I'm quite excited to see the VM go faster, especially when languages like Go and the likes are competing with Erlang/Elixir in terms of concurrency. Until then, I'll happily use: https://github.com/hansihe/rustler https://github.com/hansihe/rustler for writing NIFs in Rust.

+1000 I couldn't agree more. I have a lot of hope for BEAMJIT (or anything that will make Erlang faster per clock cycle). http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/ After reading the link above, I get the sad feeling that a faster Erlang isn't anytime soon :( With that being sad, Elixir has brought a whole new wave of people to the OTP community. Which excites me tremendously. I just hope a faster Erlang will arrive soon enough so that people needing to leave Ruby due to slowness have a good alternative with Erlang.

klibertp 8y ago
According to this talk: https://www.youtube.com/watch?v=PtgD5WRzcy4 https://www.youtube.com/watch?v=PtgD5WRzcy4 there is some (initial and under development as I understand) implementation already, with results generally 50% worse than HiPE. It looks better than any previous attempt, so maybe it's time to get a little optimistic :) Also, while additional performance never hurts, the slowness in the Erlang case is really a different kind of a problem than it is in Python or Ruby. Erlang's performance requirements are closer to those of BASH and other shells: there is no need, and no expectation, to have all the code in Erlang. The variety of options for integrating other languages should make this obvious. Even if in general Erlang is rather unimpressive in terms of performance (I'm trying to be diplomatic here...), it does have a couple of highly optimized parts, like the IO, context switching or message passing - in other words, the optimizations are focused on the things that make Erlang special and that other languages generally don't focus on. It makes Erlang often "worth it" even despite the slowness, and it works well in practice, in my experience. Elixir makes it a bit more awkward. On the one hand, it's a nice language, which is general-purpose enough to look reasonable as an implementation language for most anything. On the other, no matter the amount of pre-computations and clever macrology, it shares the same fundamental limitations that Erlang has - like a lot of copies of everything or non-inlineable calls due to how modules are made reloadable - and it's going to lead to a lot of frustration and emotional rants from people who actually tried to use it as a "reasonable, general-purpose" language without the required preparations. Even when the JIT arrives, it's not going to fit all the performance profiles equally, and the need to carefully consider the performance you need won't disappear.
- plainOldText 8y ago
  Yes, there will always be certain limitations as you've accurately mentioned. However, as a platform for writing networked web services, I think the Erlang VM is stellar. Compared to other languages, such as Go, Python, Rust, etc, the conceptual models in Erlang (processes, message passing, supervision trees) and how they all work, map better to the web problem domain. As far as the slow parts, like you said, there are plenty of choices of integrating other languages.
plainOldText 8y ago
I've never been as happy programming in a language as I've been in Elixir and its ecosystem. A complete joy! So yeah, I'm quite excited to see the VM go faster, especially when languages like Go and the likes are competing with Erlang/Elixir in terms of concurrency. Until then, I'll happily use: https://github.com/hansihe/rustler https://github.com/hansihe/rustler for writing NIFs in Rust.