> pluggable storage for Mnesia. This removes the 2GB per shard limit.
This is a pretty big deal isn't it? I've never used Mnesia but that 2GB limit was a common warning I came across in the docs and blog posts, despite noting it was a great DB to work with.
Allegedly this has already been running at Klarna in production for a while. LevelDB backend from Basho (eleveldb, it has extra optimizations and improvements besides just Erlang wrapper) has been used.
Granted 15-20 some years ago perhaps 2GB was BigData(TM) ;-)
For a while I understand you could set up sharding, so each shard is 2GB and spread shards across nodes.
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.
Haven't looked into details. But I think it is configurable. Killing is an option or just sending a message to the error logger. There was also something about it sending a special gc trace event when it hits max.
Hah, Mnesia doesn't have a 2GB limit per shard now. But having access to a leveldb backing store means you can avoid keeping the dataset resident in memory. This gives you a nice memory/latency/disk tradeoff.
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.
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 :-)
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.
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.
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.
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.
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.
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