Erlang/OTP 24 Release Candidate 1

As a heavy user of Absinthe in production, I am also very excited to hear that.

I just went to leave a slack message to my team about your report in the middle of the night, and discovered that another teammate had already just excitedly mentioned it. Thanks for what you do!

My dependencies compilation for a huge project:

OTP23 — 467.36s

OTP24rc1 — 296.16s

So nice!

If you do gen_X:call and the timeout expires before you receive a response, you may still get a response later (late reply). The timeout case can happen without a connection loss or even without distribution. I believe gen_X:call sets a monitor (maybe a link?) though, so if the server process is distributed, and the connection is lost, the call will fail; however, the server does not set a monitor on the client (to my knowledge), so when it finishes processing the message, it will reply to the client; distribution may have already reconnected, or sending the reply may cause a reconnection. I don't have great knowledge on the monitor, where I worked, we used a modified call that didn't set monitors, because it was too much overhead; we relied on timeouts instead.

If the call was part of a library function, you can return {error, timeout} or whatever, but the process you ran in will have that reply message in its mailbox, possibly forever if it only does selective receives. This will show up in your system as growing memory use, and slowing message processing (unless all of your messaging is selective receives with new references that benefits from the mailbox marking optimization).

In the proxy process alternative, you would spawn a new process to do the gen_X:call, and message back to the real client process. Any late replies get discarded as the spawned process will be dead. But spawning a process isn't free, even if an Erlang process is much lower cost than an OS thread or process. Without looking at details of the implementation, using a process alias seems like a reasonable optimization.

A lot of OTP improvements benefit whatever version of Elixir you're using or you can access directly from the erlang library (e.g. When OTP 22 came out, you could use the new socket api (:socket.open(...)).

But some additions require a new Elixir release. One that comes to mind was the new guard clause to check if a key is in a map.

Improvement to the VM or underlying stdlib that are API compatible are "free"

But. Elixir maintain a 2 otp release compatibility. So the elixir stdlib cannot use new functionality until the release of elixir in 2 years.

You can, ofc, just call the erlang lib yourself.

So on this one, you get the JIT or my float_to_string pretty printer speedup for free. But the Map module cannot use the new maps functions for 2 years.

If you use a version of Elixir built against the correct OTP release, you'll get the following automatically:

VM Performance improvements - normally this is minor but for this release it's a big big thing

Bug fixes - to standard library and VM

New Erlang APIs to use directly - you can call Erlang functions easily from Elixir, allowing you to leverage new standard library features, but they won't be used by Elixir because of the compatibility guarantees discussed elsewhere here