
Erlang R19 Release Candidate Available - dpeck
https://github.com/erlang/otp/releases/tag/OTP-19.0-rc1
======
rdtsc
Wow, lots of goodies. Erlang team has been unstoppable in the last few years.

Some changes:

* New state machine module: gen_statem (ssh module uses it as a first example).

* 3-5x times faster open_port(spawn, ...)

* Must faster and better tracing (also lttng support)

* Keeping messages off heap for processes

* mnesia-ext : pluggable storage for Mnesia. This removes the 2GB per shard limit.

* Allow limiting process's max heap usage

* Observer tool allows configuration update frequency and length of graph windows

* crypto uses EVP calls so should be accelerated by hardware were supported

* Parallel/faster module code loading

~~~
davidw
> Allow limiting process's max heap usage

What happens when it hits that limit? Crash, or try to GC, or... ?

~~~
Jtsummers
[http://erlang.org/documentation/doc-8.0-rc1/erts-8.0/doc/htm...](http://erlang.org/documentation/doc-8.0-rc1/erts-8.0/doc/html/erlang.html#process_flag-2)

Configurable, but can kill the process in question and/or log when it occurs.
Their suggestion is to log it first and tune it from there since heap size
isn't easily predictable.

EDIT: Scroll down a little bit to get this particular flag documentation.

------
educar
Awesome stuff.
[http://erlang.org/download/OTP-19.0-rc1.README](http://erlang.org/download/OTP-19.0-rc1.README)
has the complete list.

It's so beautiful to read such CHANGELOGs. The developers clearly love their
product and have put in the effort to clearly explain each change, background
and it's purpose.

~~~
im_down_w_otp
I think it's partially from an ethos driven with the hindsight of the original
core Erlang team. They wished in retrospect that they'd spent more time
documenting "why" they did something rather than "what" they did.

Not wanting to recommit sins of the past and all that :-)

------
davidw
I miss working with Erlang. I still think Ruby is better for getting something
out quickly for many businesses that charge for a product(†), but Erlang was
very interesting, challenging and generally a good community.

† If you charge for a product, you don't generally have to worry quite so much
about scaling because you make a lot more money per user than some site that's
all about ads and trying to keep the cost per user really low because the ads
don't actually pay all that much.

~~~
gjkood
Have you evaluated Elixir yet? Targets Erlang BEAM + OTP backend + Ruby like
syntax. Best of both worlds, maybe? The Phoenix framework sweetens the deal
too. I would also add Ecto ORM for popular RDBMS backends.

~~~
davidw
I haven't had a serious look at it yet, but the Ruby/Rails ecosystem is really
big. I'd bet Elixir isn't quite there yet. I like what I've seen so far,
though.

~~~
karmajunkie
I'd argue that in the vast majority of cases, anything 'missing' from the
ecosystem is probably one of those gems that probably shouldn't be a project
dependency anyway. That doesn't mean it won't filter its way over to the
Elixir ecosystem at some point, but I don't think you'll find any of the major
pieces missing.

------
cm3
You will be able to use leveldb with Mnesia in R19.

------
triptec
what does "Keeping messages off heap for processes" mean?

------
sotojuan
What are the possible implications of this for Elixir?

~~~
jlouis
Elixir immediately gets access to all of these features in the VM. Over the
next coming months, there may be the creation of more Elixir-friendly access
wrappers to the features.

However, there is the need to make sure Elixir can work with R19 in the first
place, but Jose Valim and co. has usually been quite good at getting that
working.

