* Like the gen_statem new state machine.<p>* mnesia_ext : means a whole set of new possibilities to scale Mnesia. I think Klarna started that work and was using it in production. LevelDB was used for the backend.<p>* 3-5x faster open_port means being able to start and execute external executables. Forking was basically moved to fork a special process as opposed to main VM.<p>Tracing should be a lot faster as well. This is the one I mostly exciting. Been using tracing instead of adding log statement but if it is faster, it means can do more in production with it. Saw they have lttng as well. Also worth playing with.<p>* Code loading is now parallelized. So hopefully startup should be faster.<p>* Domain sockets. I know some people wanted this for ages. This should be nice. There were external project which did it, but it is nice to see it in the VM.<p>* os:perf_counter/1 function. Probably a read out of rdtsc or such instruction. That should be fun to use.<p>* ++ operator for lists now uses a single pass, so should be faster (before used to use another pass to check if list is proper).<p>* Observer now has configurable update frequency and length for graph windows. I'll be using that. I like observer.<p>Very impressive. Not a lot of 30 some year old languages make such kind of updates (yes Erlang is 30 years old this year, that is probably older than most HNers here).
Erlang is written in a ton of quite readable C and assembly. If you like delving into the internals of advanced software, it's well worth a read. Take the HiPe compiler for example:<p><a href="https://github.com/erlang/otp/tree/OTP-19.0/erts/emulator/hipe" rel="nofollow">https://github.com/erlang/otp/tree/OTP-19.0/erts/emulator/hi...</a><p>It deals with running native and interpreted program code together, just reading the comments gives you a feel for the kind of low level concepts that go into making such an interpreter. I like this one:<p><pre><code> /*
* Native code calls an emulated-mode closure via a stub defined below.
*
* The closure is appended as the last actual parameter, and parameters
* beyond the first few passed in registers are pushed onto the stack in
* left-to-right order.
* Hence, the location of the closure parameter only depends on the number
* of parameters in registers, not the total number of parameters.
*/</code></pre>
<p><pre><code> gen_statem a new state machine behavior
</code></pre>
Very cool! For reasons not the least of which are the community involvement in its evolution.<p><pre><code> dialyzer: the support for maps is very much extended both the type specification syntax and the type analysis.
</code></pre>
OMG! Yes! Finally `maps` don't have to be a giant escape hatch in the type-checking system.<p><pre><code> Experimental support for Unix Domain Sockets
</code></pre>
Sweet tap-dancing Moses! This is awesome. I've wanted this for, so so so long. This should pave the way to all kinds of useful things. Better database clients, better Redis clients, more straightforward integration with things like libfiu and tcsd.
For anyone who's interested, we have some relevant community-run, regional conferences coming up in NYC next month:<p>- Erlang Camp (Sat Jul 16), <a href="http://erlang.camp/" rel="nofollow">http://erlang.camp/</a><p>- Elixir Camp (Jul 15-17), <a href="http://elixircamp.io/" rel="nofollow">http://elixircamp.io/</a><p>- Phoenix Camp (Jul 15-17), <a href="http://nyc.phoenix.camp" rel="nofollow">http://nyc.phoenix.camp</a><p>- Nerves Camp (Sun Jul 17), <a href="http://nerves.camp/" rel="nofollow">http://nerves.camp/</a><p>We've got a good mix of speakers coming together and the conference open to all (with suggested donation pricing for tickets).<p>We also still have a few session slots open if anyone wants to present (particularly around Erlang/OTP).
And others think building on top of BEAM is risky...<p><a href="https://news.ycombinator.com/item?id=11946824" rel="nofollow">https://news.ycombinator.com/item?id=11946824</a>