
Erlang OTP 21.0 is Released - out_of_protocol
http://www.erlang.org/news/123
======
klibertp
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
> map_get/2

super excited about this.

~~~
rehemiau
And you can use it in a ETS match spec! This will allow to reduce copying of
big maps in some use cases.

------
pera
> _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
The closest I could find is [http://blog.erlang.org/My-
OTP-21-Highlights/](http://blog.erlang.org/My-OTP-21-Highlights/)

------
judge2020
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)

------
sigsergv
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.

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

~~~
alberth
+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
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
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.

------
mikece
[https://news.ycombinator.com/item?id=17347347](https://news.ycombinator.com/item?id=17347347)

~~~
mikece
Pointing out that someone posted a dupe gets you down votes?

~~~
mercer
For my part: no, but complaining about it does.

