Erlang/OTP R14B02 has been released. | Hacker News Reader

Erlang/OTP R14B02 has been released.

erlang.org

67 pointspietrofmaggi11 comments

OTP-8941 - erlang halfword emulator (32-bit VM with 64-bit address space for non-gc data - binaries & ETS) is great fit for my data-intensive project.

Repeating type specs twice was very annoying - now edoc will pick up type specs.

For those of us that don't do Erlang, is this a big deal?

The EDoc improvements are a long time coming, and the halfword emulator may drastically reduce the amount of memory needed for some people.

Erlang improves at quite a rapid pace for a mature language.

Could you (or anyone else) explain Erlang's release number scheme?

Is R14 the 14th major release and B02 a minor release? Is there some other meaning in their numbering? (Sorry, my Google-fu is failing miserably on this topic)

You can look in this table (2nd column):

http://erlang.org/download.html

R means release

14 is the major release number

B is the minor release 'number'. By convention, 'A' is not considered ready for production, whereas 'B' and later are.

02 is the 'patch level', i.e. an even more minor release number

This scheme, or at least the part up to the 'B', was used all over the place in Ericsson while I was there (a decade ago). I just pulled the battery off my phone to see if it was still used and it doesn't seem to be. One of my previous mobile phones had R1F on the sticker behind the battery...

This is exactly what I was looking for, thank you!

If you are not an existing Erlang user, there is no sudden change here that should drive you to try it specially. Erlang is a mature platform and is beyond that in the same way that Python or Ruby is beyond it; yes, the next version of Python or Ruby will have some nice improvements but they are extremely unlikely to have something that will make a non-Python or Ruby user suddenly cry out "Yes, suddenly this is an acceptable solution where it never was before!"

The big changes that struck me were for scalability of deployed systems, which a new user won't care about as they don't have deployed systems by definition. The 32-bit Erlang process memory space in a greater 64-bit system is really interesting in a number of ways. It's certainly a common Erlang deployment pattern where no one Erlang process needs more than even a handful of megabytes necessarily, but the system as a whole runs past several gigabytes by sheer scale of accumulated processes that themselves may only have hundreds of bytes allocated. I've also got a use for smaller SSL footprints.

"It's certainly a common Erlang deployment pattern where no one Erlang process needs more than even a handful of megabytes necessarily, but the system as a whole runs past several gigabytes by sheer scale of accumulated processes that themselves may only have hundreds of bytes allocated."

From the release notes, it looks like the 32-bit emulator restricts the total for all processes to 4GB. Only ETS tables and off-heap binaries don't count toward that total.

Thanks for the correction, re-reading it that seems likely. Less useful, then. Not useless (you can "cluster" Erlang with multiple instances on one system), but less useful.

It's less usefull if you running a Web or Comet server (were you have one or more processes per client).

It's usefull if you writing a control middleware handling a lot of data buffers, i.e. NoSQL database or MQ server.

Reply on news.ycombinator.com