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

Mark Nijhof mark.nijhof@REDACTED
Sat Feb 1 22:21:43 CET 2014


Thanks for the replies so far!

Interesting to see that people don't like using records past module
boundaries, we extensively use them that way (which might change with the
new map feature). In our solution we have a few "data types" that get
passed around to different processes to do things, and also we use
something like a message bus to have subscribe/unsubscribe functionality
for which we use records as messages. For us this works really well, proven
by the countless refactorings being done (inside processes but also
complete restructuring of how processes are tied together).

Now I am not saying you are wrong obviously, but thought it was worth
putting this "other" experience in the group as well.

-Mark



On Sat, Feb 1, 2014 at 10:08 PM, Loïc Hoguin <essen@REDACTED> wrote:

> I think for most users and most use cases maps will completely take over
> records.
>
> 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 horribly:
> http://erlang.org/pipermail/erlang-questions/2014-February/076765.html
>
> 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 entirely.
>
> </Reasons>
>
> 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
> http://ninenines.eu
>



-- 
Mark Nijhof
t:   @MarkNijhof <https://twitter.com/MarkNijhof>
s:  marknijhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140201/874fe1a0/attachment.htm>


More information about the erlang-questions mailing list