5 ms·

Erlang OTP 21.0 is Released

pera 8y ago
> Misc compiler optimizations including contributions from the Elixir team resulting in 10% improvements in benchmarks That sounds great! where can I see these benchmarks?
- sntran 8y ago
  The closest I could find is http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/
- shakna 8y ago
  They're using Bjorn's benchmark suite [0] as part of the test server. Not sure when updated last, but you can see some results here. [1] [0] http://www.erlang.org/download/bstone.tar.z http://www.erlang.org/download/bstone.tar.z [1] http://www.erlang.se/~bjorn/benchmarks2/ http://www.erlang.se/~bjorn/benchmarks2/
- rehemiau 8y ago
  Some small benchmarks are at https://michal.muskala.eu/2018/06/20/my-otp-21-highlights.html https://michal.muskala.eu/2018/06/20/my-otp-21-highlights.ht...
judge2020 8y ago
If you're getting a Symantec certificate error, try loading the non-https version. There is an open issue for this on the erlang.org repo: https://github.com/erlang/erlang-org/issues/7 https://github.com/erlang/erlang-org/issues/7
klibertp 8y ago
Also worth reading, the blog post with highlights for the release: http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/ and the release notes with all the technical details you'd like to know: http://erlang.org/download/otp_src_21.0.readme http://erlang.org/download/otp_src_21.0.readme A few of the things I noticed: > Two new guards BIFs operating on maps have been added: map_get/2 and is_map_key/2. They do the same as maps:get/2 and maps:is_key/2, respectively, except that they are allowed to be used in guards. This is great and further enhances usefulness of both the maps, and the guards, which is always a good thing. > There is a new syntax in 'try/catch' for retrieving the stacktrace without calling 'erlang:get_stacktrace/0'. See the reference manual for a description of the new syntax. The 'erlang:get_stacktrace/0' BIF is now deprecated. You can now get the stacktrace when matching exceptions in the `catch` section of `try`, like `error:Exception:Stacktrace -> handler_code()`. > A new logging API is added to Erlang/OTP, see the logger(3) manual page, and section Logging in the Kernel User's Guide. I felt for a long time that configuring logging on the BEAM was a kind of dark art, and never really understood what goes where between SASL, error_logger, lager, and other tools. Now it got properly unified, from what I read, which should make it much easier to configure and use proper logging. That's great! As a bonus, Elixir already supports the new logger[1], apparently. Other than that there seem to be a lot of optimizations, in the compiler, in the emulator, in the IO system, and in signal handling. Also a lot of bugfixes, and some smaller conveniences like an iterator for maps. All in all nothing as exciting as the introduction of maps (unless I'm missing something), but a pretty solid release anyway. [1] https://github.com/elixir-lang/elixir/pull/7649 https://github.com/elixir-lang/elixir/pull/7649
- dnautics 8y ago
  > map_get/2 super excited about this.
  - rehemiau 8y ago
    And you can use it in a ETS match spec! This will allow to reduce copying of big maps in some use cases.
mikece 8y ago
https://news.ycombinator.com/item?id=17347347 https://news.ycombinator.com/item?id=17347347
- mikece 8y ago
  Pointing out that someone posted a dupe gets you down votes?
  - mercer 8y ago
    For my part: no, but complaining about it does.
plainOldText 8y ago
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.
sigsergv 8y ago
If you are using tuple calls be careful updating because in this version they are removed. You can use erlc option tuple_calls to bring them back but in some cases it doesn't work. Particularly ChicagoBoss is very broken now.

pera 8y ago

> Misc compiler optimizations including contributions from the Elixir team resulting in 10% improvements in benchmarks That sounds great! where can I see these benchmarks?

sntran 8y ago
The closest I could find is http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/
shakna 8y ago
They're using Bjorn's benchmark suite [0] as part of the test server. Not sure when updated last, but you can see some results here. [1] [0] http://www.erlang.org/download/bstone.tar.z http://www.erlang.org/download/bstone.tar.z [1] http://www.erlang.se/~bjorn/benchmarks2/ http://www.erlang.se/~bjorn/benchmarks2/
rehemiau 8y ago
Some small benchmarks are at https://michal.muskala.eu/2018/06/20/my-otp-21-highlights.html https://michal.muskala.eu/2018/06/20/my-otp-21-highlights.ht...

judge2020 8y ago

If you're getting a Symantec certificate error, try loading the non-https version. There is an open issue for this on the erlang.org repo: https://github.com/erlang/erlang-org/issues/7 https://github.com/erlang/erlang-org/issues/7

klibertp 8y ago

Also worth reading, the blog post with highlights for the release: http://blog.erlang.org/My-OTP-21-Highlights/ http://blog.erlang.org/My-OTP-21-Highlights/ and the release notes with all the technical details you'd like to know: http://erlang.org/download/otp_src_21.0.readme http://erlang.org/download/otp_src_21.0.readme A few of the things I noticed: > Two new guards BIFs operating on maps have been added: map_get/2 and is_map_key/2. They do the same as maps:get/2 and maps:is_key/2, respectively, except that they are allowed to be used in guards. This is great and further enhances usefulness of both the maps, and the guards, which is always a good thing. > There is a new syntax in 'try/catch' for retrieving the stacktrace without calling 'erlang:get_stacktrace/0'. See the reference manual for a description of the new syntax. The 'erlang:get_stacktrace/0' BIF is now deprecated. You can now get the stacktrace when matching exceptions in the `catch` section of `try`, like `error:Exception:Stacktrace -> handler_code()`. > A new logging API is added to Erlang/OTP, see the logger(3) manual page, and section Logging in the Kernel User's Guide. I felt for a long time that configuring logging on the BEAM was a kind of dark art, and never really understood what goes where between SASL, error_logger, lager, and other tools. Now it got properly unified, from what I read, which should make it much easier to configure and use proper logging. That's great! As a bonus, Elixir already supports the new logger[1], apparently. Other than that there seem to be a lot of optimizations, in the compiler, in the emulator, in the IO system, and in signal handling. Also a lot of bugfixes, and some smaller conveniences like an iterator for maps. All in all nothing as exciting as the introduction of maps (unless I'm missing something), but a pretty solid release anyway. [1] https://github.com/elixir-lang/elixir/pull/7649 https://github.com/elixir-lang/elixir/pull/7649

dnautics 8y ago
> map_get/2 super excited about this.
- rehemiau 8y ago
  And you can use it in a ETS match spec! This will allow to reduce copying of big maps in some use cases.

mikece 8y ago

https://news.ycombinator.com/item?id=17347347 https://news.ycombinator.com/item?id=17347347

mikece 8y ago
Pointing out that someone posted a dupe gets you down votes?
- mercer 8y ago
  For my part: no, but complaining about it does.

plainOldText 8y ago

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.

sigsergv 8y ago

If you are using tuple calls be careful updating because in this version they are removed. You can use erlc option tuple_calls to bring them back but in some cases it doesn't work. Particularly ChicagoBoss is very broken now.