Erlang/OTP 19.0 has been released(erlang.org)
erlang.org
Erlang/OTP 19.0 has been released
http://www.erlang.org/news/105
43 comments
Regarding Klarna's work on LevelDB + ETS, there's this wonderful presentation given by Mikael: https://vimeo.com/132692834
Here's the slides: http://www.erlang-factory.com/static/upload/media/1434153406...
Here's the slides: http://www.erlang-factory.com/static/upload/media/1434153406...
Very nice. Thank you!
With `os:perf_counter/1` also comes msacc aka microstate accounting. Thanks @garazdawi :)
http://erlang.org/documentation/doc-8.0-rc1/lib/runtime_tool...
http://erlang.org/documentation/doc-8.0-rc1/lib/runtime_tool...
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:
https://github.com/erlang/otp/tree/OTP-19.0/erts/emulator/hi...
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:
https://github.com/erlang/otp/tree/OTP-19.0/erts/emulator/hi...
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.
*/Looks like it has gotten a lot better than "Now for the tricky bit" days.
See https://youtu.be/lKXe3HUG2l4?t=640
See https://youtu.be/lKXe3HUG2l4?t=640
gen_statem a new state machine behavior
dialyzer: the support for maps is very much extended both the type specification syntax and the type analysis.
Experimental support for Unix Domain Sockets
I cannot find the documentation for gen_statem anywhere; all I find is references to some specific examples.
From the docs:
"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.
"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.
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.
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.
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.
Ah, thank you!
For anyone who's interested, we have some relevant community-run, regional conferences coming up in NYC next month:
- Erlang Camp (Sat Jul 16), http://erlang.camp/
- Elixir Camp (Jul 15-17), http://elixircamp.io/
- Phoenix Camp (Jul 15-17), http://nyc.phoenix.camp
- Nerves Camp (Sun Jul 17), http://nerves.camp/
We've got a good mix of speakers coming together and the conference open to all (with suggested donation pricing for tickets).
We also still have a few session slots open if anyone wants to present (particularly around Erlang/OTP).
- Erlang Camp (Sat Jul 16), http://erlang.camp/
- Elixir Camp (Jul 15-17), http://elixircamp.io/
- Phoenix Camp (Jul 15-17), http://nyc.phoenix.camp
- Nerves Camp (Sun Jul 17), http://nerves.camp/
We've got a good mix of speakers coming together and the conference open to all (with suggested donation pricing for tickets).
We also still have a few session slots open if anyone wants to present (particularly around Erlang/OTP).
Exciting two days in Elixir world! Elixir 1.3, Ecto 2.0, Erlang/OTP 19 - amazing!
Phoenix is hinting that 1.2 might drop too https://twitter.com/elixirphoenix/status/745265003775823872
aaaaand there it is! https://github.com/phoenixframework/phoenix/releases/tag/v1....
I'm soooo happy right now! :)
Supposedly they were just waiting for Ecto 2 to be finalized before releasing.
Ecto is 2.0, awesome. Just was busy there days, didn't pay attention.
Everything around the Erlang\Elixir ecosystem just seems to be in a dramatic climb these days.
totally agree, lots of activity/interest in NYC
And others think building on top of BEAM is risky...
https://news.ycombinator.com/item?id=11946824
https://news.ycombinator.com/item?id=11946824
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.
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.
erlang:open_port(spawn, ...) 3-5 times faster
mnesia_ext: plugin of external storage solutions to mnesia
mnesia_ext: plugin of external storage solutions to mnesia
Ah nice! ..wonder if mnesia_ext is bundled with leveldb support?
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.
> LMDB was marked as being prone to data corruption
Don't know where you got your information from, but LMDB is verified as the safest storage engine:
https://www.usenix.org/conference/osdi14/technical-sessions/...
Don't know where you got your information from, but LMDB is verified as the safest storage engine:
https://www.usenix.org/conference/osdi14/technical-sessions/...
Sorry, I was thing about LevelDB. ANd yes, you are right about LMDB!
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.
I have a very modest experience with it, but when a crash happened it was game-over for it. Maybe I was doing something wrong.
No. The actual ext is something you have to provide yourself.
Amazing! Now how do I use Elixir 1.3 with the new Erlang VM?
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].
[1]: https://github.com/asdf-vm/asdf
If you want an easy way to install both, you can check asdf [1].
[1]: https://github.com/asdf-vm/asdf
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).