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

[Fred Hebert]

I agree here. I do not see maps replacing records. I do not want to see
them replacing records either.

Maps should be a replacement of data structures like dicts and gb_trees,
in my opinion, but I still prefer records within a module module, where
I feel their restrictiveness is welcome, for two main reasons:

1. crash early in live code upgrades, despite, I'm sure, a
   lot of people disagreeing with me.

   A badly planned upgrade should die rather than leading to corrupted
   state. If you're crashing in your record conversion, be thankful
   you're not running with bad state introducing subtle bugs (and
   shameful of not having planned your upgrade better, in a way!)

2. The module isolation inherent to records makes people think at a
   protocol level and with their API much, much better than the common
   pattern of saying "screw it", sharing the state around, and breaking
   abstraction all over. I like how it constrains the programmer to think
   of what should be passed around in messages, and that maps may remove
   that "think hard" part of the problem.

   APIs are hard, and the restrictions record bring forth are welcome to me.

Maps should be especially nice and enable more complex dictionary
manipulations, nested key/val mapping, and so on, and in terseness of
operations. More elegantly, they could be a decent fix to 'use ETS to
optimize K/V operations', although they won't benefit from the same
parallel access.

I plan to explain this and possibly revisit some code snippets from the
Learn You Some Erlang site in an add-on chapter, and also show what I
wouldn't change.

Regards,
Fred.

On 02/01, 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