[erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released.

Loïc Hoguin essen@REDACTED
Sat Feb 1 22:08:59 CET 2014

I think for most users and most use cases maps will completely take over 

Reason 1: Records today are already only usable inside a single module.

Records need to be defined. This means that if you want your record to 
be available across more than one module you need to either duplicate 
the definition or put it in an include file. But doing this means that 
you're leaking out the record definition all across your application, 
which makes changing said definition harder (and code upgrades almost 
impossible to get right).

A good practice deriving from that is to make sure records never leave 
one module, or at the very least that they never get accessed from 
outside that module (using -opaque). That makes records workable, but 
limits their usefulness.

Reason 2: Upgrading a process state that uses records is terrifying.

Well here's a good explanation of why it's terrifying and sucks 

For maps at worst you just do M#{ new_field => default_value } and are 
done with it.

Reason 3: Records are cumbersome to use.

Many hate the record syntax. Many also would prefer to avoid the record 
definition entirely when prototyping some code. And they should! Maps 
aren't slowing down your work the way records do. And guess what. Most 
of the time the prototype of an Erlang process is good enough for 
production use.

You lose Dialyzer. That's the big drawback. But most processes' state is 
smallish so mistakes are hard to make and quickly found anyway.

Some will also argue that records are FAST and maps aren't. But for most 
processes it doesn't matter. And I will even go as far as saying that 
this isn't necessarily true. Records allocate fully at creation, maps 
only when needed. You can easily only set keys that are different from 
the defaults in the map, keep it small and potentially beating records 


These are the three main reasons I think maps will take over. Personally 
I will probably still use records for most processes' state because I 
like Dialyzer, might consider using records where speed is a huge 
requirement (after careful measurements) but anywhere else? Maps. Maps 
all the way, baby.

Maps will also completely beat proplists to death, burn their brackets 
and eat their hearts. I don't think I need to explain why.

Seeing maps used in place of records will probably not make everyone 
happy. Oh well. They might even say you're WRONG (madness!) to use them 
in this or that scenario, and insistently ask WHY you are doing 
something so CRAZY. But you know. Whatever works.

On 02/01/2014 06:30 PM, Mark Nijhof wrote:
> Hi Joe (and the rest of the list),
> Ok right up front, I'm not a Guru, I have only been working with Erlang
> for about 7 happy months :-)
> I have a question about the "Records are dead - long live maps"
> statement you make in your post. One of the nice things I like about
> records is is that they are a "typed" collection of key->value pairs.
> When I pass a record around I can look up the definition and know what I
> can and cannot do with it, and also see what a function expects. Also
> pattern matching purely on the record type is a great initial filter.
> When I look at maps they look more like a proplist replacement,
> something that is just as flexible (more so I guess) but with better usage?
> So the question really is, how do you see maps replacing records? Would
> we add a map_type property to the map to distinguish between different
> maps? Or purely on it's data structure it self?
> If this is a silly question then I am happy to read about it in one of
> your awesome rants.
> -Mark
> On Sat, Feb 1, 2014 at 5:34 PM, Joe Armstrong <erlang@REDACTED
> <mailto:erlang@REDACTED>> wrote:
>     On Fri, Jan 31, 2014 at 10:51 PM, Kenneth Lundin
>     <kenneth.lundin@REDACTED <mailto:kenneth.lundin@REDACTED>> wrote:
>         Erlang/OTP 17.0-rc1 has been released.
>     Fantastic - great - this is a major change to Erlang.
>     I've written an article that documents the biggest changes.
>     Big changes to Erlang
>     http://joearms.github.com/2014/02/01/big-changes-to-erlang.html
>     Cheers
>     /Joe
>         This is an alpha release, which will be followed by a planned
>         beta release about a month later and a final
>         OTP 17.0 product release in the end of March 26, 2014.
>         Between the alpha and beta and final release there will be new
>         updates of the master branch with corrections
>         and minor new features. Occasionally there might be new tags
>         which we in that
>         case will communicate and ask you to test.
>         Erlang/OTP 17.0 is a new major release with new features, quite
>         a few (characteristics) improvements,
>         as well as some incompatibilities. See the README file and the
>         documentation for more details.
>         We would like to ask you to download and test the alpha release
>         and send us your feedback as soon as possible,
>         so that we can make the necessary corrections before OTP
>         17.0-rc2 and OTP 17.0, respectively.
>         The release contains many changes; thus, some unexpected
>         incompatibilities or issues may have slipped through
>         our tests. Please try to build and run your current
>         products/applications and let us know about any problems.
>         Note! The new datatype MAP is not properly documented yet but
>         the EEP 43 http://www.erlang.org/eeps/eep-0043.html
>         will provide a good start. Also note that it is a limited
>         implementation of maps implemented so far:
>              - no variable keys are allowed
>              - native code can not be generated for modules using maps
>         Some other highlights of the release are:
>              - Maps, a new dictionary data type (experimental)
>              - A more natural mapping from ASN.1 OCTET STRING and BIT
>         STRING to Erlang types,
>                and other ASN.1 improvements and optimizations
>              - The {active, N} socket option for TCP, UDP, and SCTP
>              - A new (optional) scheduler utilization balancing mechanism
>              - Migration of memory carriers has been enabled by default
>         on all ERTS internal
>                memory allocators
>              - Increased garbage collection tenure rate
>              - Experimental "dirty schedulers" functionality
>              - Funs can now be given names
>              - Miscellaneous unicode support enhancements
>              - A new, semantic version scheme for OTP and its applications
>         You can find the README file with more detailed info at
>         http://www.erlang.org/download/otp_src_17.0-rc1.readme
>         You can download the full source distribution from
>         http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz
>         http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file)
>         Note: To unpack the TAR archive you need a GNU TAR compatible
>         program.
>         For installation instructions please read the README that is
>         part of the distribution.
>         You can also find this release at the official Erlang/OTP
>         Git-repository at Github here:
>         https://github.com/erlang/otp tagged *OTP_17.0-rc1*
>         The Windows binary distribution can be downloaded from
>         http://www.erlang.org/download/otp_win32_17.0-rc1.exe
>         http://www.erlang.org/download/otp_win64_17.0-rc1.exe
>         On-line documentation can be found at http://www.erlang.org/doc/.
>         You can also download the complete HTML documentation or the
>         Unix manual files
>         http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz
>         http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz
>         We also want to thank those that sent us patches, suggestions
>         and bug reports.
>         The Erlang/OTP Team at Ericsson
>         _______________________________________________
>         erlang-questions mailing list
>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>         http://erlang.org/mailman/listinfo/erlang-questions
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
> --
> Mark Nijhof
> t: @MarkNijhof <https://twitter.com/MarkNijhof>
> s:  marknijhof
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Loïc Hoguin

More information about the erlang-questions mailing list