> 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.
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
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.
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.
According to this talk: 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.
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.
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.
and the release notes with all the technical details you'd like to know: 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