* 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.
* 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.
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.
* Code loading is now parallelized. So hopefully startup should be faster.
* 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.
* os:perf_counter/1 function. Probably a read out of rdtsc or such instruction. That should be fun to use.
* ++ operator for lists now uses a single pass, so should be faster (before used to use another pass to check if list is proper).
* Observer now has configurable update frequency and length for graph windows. I'll be using that. I like observer.
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:
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:
/*
* 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.
*/
Very cool! For reasons not the least of which are the community involvement in its evolution.
dialyzer: the support for maps is very much extended both the type specification syntax and the type analysis.
OMG! Yes! Finally `maps` don't have to be a giant escape hatch in the type-checking system.
Experimental support for Unix Domain Sockets
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.
"This is a new behavior in Erlang/OTP 19.0. It has been thoroughly reviewed, is stable enough to be used by at least two heavy OTP applications, and is here to stay. Depending on user feedback, we do not expect but can find it necessary to make minor not backward compatible changes into Erlang/OTP 20.0."
It's honestly hard to overstate how excellent seeing that note is. It's a significant change in tone regarding community involvement in the design, structure, and implementation of core OTP components. It's really exciting to see.
I can't help but see this as part of a halo-effect that originates in the inclusive and thriving community around Elixir. It really seems like both ecosystems are getting a lot from each other right now.
I think it's probably more of a consequence of the long long discussions that were had at https://github.com/erlang/otp/pull/960 -- with 15 participants from the OTP team, regular Erlangers, and I'm sure a few Elixir people too.
My idea here is not to remove merit from Elixir in helping the ecosystem, but in pointing out that the Erlang community itself is expanding on these ideas of involvement and a more open design.
Wow, that thread is impressive. I think I've never seen a Github thread that long, complex, and yet with such politeness.
The internet may have ruined me, but I somehow expected the thread to end up in insults and nasty things after a while; and here I am, amazed. Really well done.
Oh I absolutely agree. That was a lively and excellent discussion, and my comment had more to do with increased openness and engagement on the part of Ericsson proper to being more involving and ambitious with respect to outside influences than it had to do with contrasting the Erlang community with the Elixir community.
Also... I have a "6x Programmer" hat for you the next time I see you. When you mentioned it after seeing my "#7 Dad" hat at EF SF, I couldn't help but have a couple made.
The OTP team and the community have made a concerted effort to work more together that has been in the process for years now. Even the community based build tool rebar3 is being adopted into the official Erlang/OTP ecosystem.
I honestly don't get that comment. It quickly mentions that the BEAM hasn't got a bright future, and then goes on the qualities of Scala, and how Ruby was horrible.
How does that contribute IN ANY WAY to a thread about a new version of Elixir being released? I'm not saying that what they say it's wrong, just tremendously out of context and unnecessary.
I'd rather have Bitcask or RocksDB - something that has better crash recovery capabilities. LevelDB was marked as being prone to data corruption. DETS has similar problems when not closed properly.
DETS is supposed to repair itself on startup. I think most crash-only systems work that way (on startup, start reading from end and find last consistent bit and chop off the rest). But there could obviously been a bug there.
You just install the new Erlang VM, install Elixir 1.3, and that's it!
Elixir 1.3 is compatible with Erlang 19, and will by default use the Erlang installation available on the path, so nothing to do in particular.
If you want an easy way to install both, you can check asdf [1].
Elixir is currently already compatible with Erlang 19. The work for adding support for the new features to Elixir is being worked on/tracked here: https://github.com/elixir-lang/elixir/issues/4617
* 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.
* 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.
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.
* Code loading is now parallelized. So hopefully startup should be faster.
* 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.
* os:perf_counter/1 function. Probably a read out of rdtsc or such instruction. That should be fun to use.
* ++ operator for lists now uses a single pass, so should be faster (before used to use another pass to check if list is proper).
* Observer now has configurable update frequency and length for graph windows. I'll be using that. I like observer.
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).