• You want to get into actor-based (and message-passing-based) concurrency
  
• You want to program in a functional language that can land you jobs and build products¹
  
• You need to build reliable and fault-tolerant server-side software
  
• You need to build a low-latency application or one that requires massive concurrency
  
• Hey, experience is experience, so why not?
  

• Official website. The documentation page has links to a few courses
  
• Learn You Some Erlang is often recommended as a free source (disclaimer: I wrote that one).
  
• RosettaCode has a bunch of Erlang tasks to learn from or to use as exercises
  
• The wikibook that exists appears to be nice, but I have never read it myself.
  

• http://erlangcentral.org/jobs/
  
• http://totally-erlang.com/en/
  

• Official Site
  
•  Official Doc
  
• Mailing Lists (erlang-questions is the most active one)
  
• IRC Channel: #erlang on freenode
  
• Talks: from the Erlang factory conferences, InfoQ, some others on Vimeo
  

• Replace Erlang records for their current use case (fast, internal state of a process with pattern matching, static records, much like a C struct, addressable by keys, which should be atoms and static)
  
• Can be used cross-modules without sharing definitions in .hrl files (a wart of records)
  
• Keep things as efficient as current records (which are basically tuples)
  
• Can be seen as its own data type (i.e. not a tuple as the underlying structure)
  
• No absolute need for O(1) updates, and said updates should be functional (not in-place)
  

• Replace dicts in their current use cases, and make them nicer to use with pattern matching
  
• Provide a faster implementation (likely native)
  
• No direct hope to replace records, but that requirement is open to be stapled on later.
  
• Arbitrary keys and number of elements
  
• Maps should respect global sort order even with arbitrary keys and elements -- because you want to pattern match on them, you need to be able to compare them by {Key,Value}, and they want better comparison than O(n log n).
  
• It should be possible to have a way to differentiate between adding and updating a key.
  

true  = 1 == 1.0,
false = 1 =:= 1.0,
1 = 1, % works
1 = 1.0. % crashes

• The choice of operators and their semantic is not ideal, but in the end you can't do much about it because of the difference between floats and integers. Some people found it a lot less ideal than others.
  
• There was a debate about whether we really needed frames or maps more than the other, or if one could do both at once. This is still up in the air, but the OTP team said they don't intend for Maps to replace Frames.
  
• Syntax of nested updates were debated, with alternative recommendations. Most vocal people found out that the syntax suggested in the draft proposal was good enough as is.
  
• Questions were asked regarding the underlying implementation. In past conferences, the OTP team hinted at HAMTs being used, but given the need for ordering, they are not applicable there. People talked about such implementations, compared them to frames, discussed tradeoffs, etc. I do not think the OTP team has settled on any specific implementation at this point, and they're open to the idea of having different implementations depending on the map size (they should transition up/down automatically).
  

MononcQc fucked around with this message at 19:50 on May 21, 2013