Here it comes!
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?
1 Like
Pretty sure @josevalim contributed that patch. SoâŚyea. 
4 Likes
âTuple callsâ have been removed from the run-time system.
8 Likes
Donât worry, youâll get your OCaml-style modules some other way 
5 Likes
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. 
1 Like
This is a GOOD thing! They were trying to sneak in OO through a back door. 
6 Likes
But with OO the BEAM could become Enterprise-Ready like Java â˘!
3 Likes
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!
2 Likes
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.
