Code such as f({ok, Val}) → {ok, Val} is now automatically rewritten to f({ok, Val} = Tuple) → Tuple. this reduces code size, execution time, and removed GC pressure.

@josevalim Is Elixir gonna make use of that?

Pretty sure @josevalim contributed that patch. So..yea.

“Tuple calls” have been removed from the run-time system.

Don’t worry, you’ll get your OCaml-style modules some other way

Yes, it will, just mentioning (correct me if I’m wrong please) this is on compilation, so the compiled version of f({ok, Val}) -> {ok, Val} and f({ok, Val} = Tuple) -> Tuple are the same, but the code stays the same. So if you use OTP 21 with your Elixir, you’re already using that by default.

This is a GOOD thing! They were trying to sneak in OO through a back door.

But with OO the BEAM could become Enterprise-Ready like Java ™!

Misc compiler optimizations including contributions from the Elixir team resulting in 10% improvements in benchmarks

Wow, good job!

Creation of small maps with literal keys optimized.

And this is of course also something that our map-heavy language will love !

Support for usage of distribution controller processes for alternative transports, routing etc

Do I hear Partisan and friends coming rapidly nearer? Very cool news for everyone who is into distributed systems, I think!

Congrats, Erlang team!

Nah, tuple calls are fantastic to emulate first class module functors! Those can also handle ‘most’ of what OOP does as well, except when the compiler implements it well then it can become very efficient (though the beam doesn’t, but, say, OCaml does).

Now there is no way to emulate it as such, have to manually destructure and all now, which makes witness and such things much less opaque.

Seeing them only as an OOP construct is extremely limiting.