Hacker News Reader

Comment by lkrubner | Hacker News Reader

I love this:

"Key := Val Updates an existing Key The key must be present in the old map. If Key is not in the old map Erlang will complain loudly. Using two operations instead of one has several advantages: A spelling mistake cannot accidentally introduce a new key"

Lord knows how many times I accidentally created a new key with a spelling typo, and then later when I wanted to retrieve the data, I was like "What the hell is wrong? I know I put data in that key, so why is nothing coming back? I guess I have discovered a rare bug in the compiler that no one has ever discovered before."

View on HN

I also like how such rather large changes are being introduced in a language that has been in production for many decades. That is pretty remarkable.

I think Erlang is sort of unique in this way. Many languages go through a lot of changes when they are not all that popular, and then blow up in popularity and finally have a lot of users who are wary of Big Changes. Ruby, for instance, was around for years and years before it started to get popular because of Rails. Python, too, was a product of the early 90ies, but as late as some Linux conference in... '99 or 2000 or thereabouts, I recall sitting at a BoF table with Guido and just a few other people, and the language not being that big a deal.

Erlang is still not really all that popular, but has always had a lot of Important Code in production thanks to Ericsson, which has made it more difficult to change even though there are some things that even the creators acknowledge as not particularly elegant.

It is funny Erlang is one of those languages and run-times that is used quite a bit without people knowing about. Its reliability properties put at the core of many services (Facebook chat, Amazon, phone gateways etc).

It is both a blessing and a curse. If a service or program doesn't crash and cause a lot of drama and headaches it also doesn't get noticed in a certain way.

I forgot who mentioned it (one of Erlang Factory talks probably), but for example if you access the Internet via your smart phone, there is like a 30% change that it goes through Erlang at some point (due to going through Ericsson's servers).

I seem to recollect reading about Facebook Chat getting rewritten in C++. Maybe here somewhere?

I also remember seeing such comments on HN, but all the references I could find searching just now say a combination of Erlang and C++ is used for FB Chat.

> I forgot who mentioned it (one of Erlang Factory talks probably), but for example if you access the Internet via your smart phone, there is like a 30% change that it goes through Erlang at some point (due to going through Ericsson's servers).

yes there is probably > 30% chance of that. the space that you are looking for is mobile-packet-core, and is dominated by ericsson, csco (via starent acquisition), and to a lesser degree by alu, nsn etc.

> ... has always had a lot of Important Code in production thanks to Ericsson, which has made it more difficult to change...

Google basically solved this problem for themselves with gofix. I'm surprised Erlang doesn't have an equivalent, given that it would basically just be a reuse of the "parse transform" code.

Erlang dates back to sometime in the late 80ies, so I don't know if it's quite as simple as all that. Some systems are things you really don't want to mess with, and a Pareto (80/20) tool won't cut it.

Rather large change? As far as I understand it's just adding a new built-in collection and literal form for it (oh, and the pattern-matching machinery for it obviously).

Python added a set builtin in 2.4 and a literal syntax in 2.7, Objective-C added NSNumber, NSArray and NSDictionary literals only last year.

I think it is a rather significant change.

It is like adding built-in maps to C++ or Java or C. Python set was similar. And there was talk about whether {} should be an empty set or a dict. It stayed a dict. I remember it.

But also in mid 90's already large production systems were written in Erlang while Python was still experimental. Python 2.0 was released in early 2000s or so.

> I think it is a rather significant change.

"Significant" and "large" are different things. A change can be small and significant, and large and insignificant.

> It is like adding built-in maps to C++ or Java or C.

It's like adding built-ins to anything. Your point?

> Python set was similar.

Similar what? It was a new builtin and literal to a language which did not have a builtin (let alone literal) set.

> And there was talk about whether {} should be an empty set or a dict.

Which is relevant how? Also not really, `{}` becoming an empty set literal was taken off the table more or less immediately when the introduction of set literals was being discussed.

> But also in mid 90's already large production systems were written in Erlang while Python was still experimental. Python 2.0 was released in early 2000s or so.

You're joking right? Python 2.0 was released in 2000 (October), which would quite obviously mean that Python 1 had preceded it by a few years (6), and most things are usually considered not experimental by the time they reach version 1. Python had stopped being experimental more than a decade before sets were added.

> It is like adding built-in maps to C++ or Java or C. It's like adding built-ins to anything. Your point?

If you'd read my comment you'd understand. The point was that adding a new built-in to an almost a 30 year old language is unusual. Adding a new built-in to Dart is probably a lot easier. So not it is not "like adding built-ins to anything".

> > Python set was similar. > Similar what?

Wild guess but well I don't know the topic we are discussing -- maps to Erlang. And by extension adding a major built-in type to any established language.

> > And there was talk about whether {} should be an empty set or a dict. Which is relevant how?

It is not. Just making conversation remembering from years back. Sheesh...

You're comparing apples to oranges. Implementing a data structure in one language cannot be compared to implementing a data structure in a different one.

I don't want to sound pessimistic, but adding a map structure to an language sounds rather small to me.

To a new and experimental language it would be a small change. Try adding a built-in map to C or Java. Lambda expressions took year to add to Java for example.

Now if say Nimrod or Dart acquired built-in sets (I don't know maybe it already does) it wouldn't be too remarkable. They are pretty experimental.

Also there is a difference between having a library and a language built-in. All those languages including Erlang, have libraries that provide associative data structures.

I don't understand. By built-in map you mean "map literals"?

Yes, as built-ins I consider literals (with specific language syntax). Well, otherwise most modern useful languages have at least a library level implementation of some associative data structures. Erlang has them too, dict, gb_tree and a few others.

Off my head:

Support the runtime, support the syntax and semantics, change the pattern matcher, write extensive tests, add it to the term_to_binary/binary_to_term protocol, add it to distribution, enable reading of maps in various function calls, enable NIFs to inspect maps, define how to copy maps between processes, change the core compiler.

It isn't so simple.

It's not the grammar footprint that makes it a large change. It's that a lot of people will change the way they write erlang programs now that maps exist.

You'd have to understand more about Erlang semantics to appreciate it. Those who have used Erlang or hacked the Erlang language itself know this to be nontrivial.

many = 2 ?

To counteract such bugs I usually try to use as short names as possible. I mean, there is no point in writing productionDatabase when prodDb works just as well. It has several advantages but one of them is that the latter is much less likely to be misspelled.

I'd say the latter is much more likely to be misspelled since you abbreviated it arbitrarily. It's easy to write it prodDB or proddb, or was is productionDb?

Using actual English names actually minimizes the risks of mistakes.

And of course, using a statically typed language makes all these concerns moot since the compiler won't let you make these mistakes in the first place.

Static typing does nothing for hashes/maps. That would only help with attributes on objects.

Right, but the example code would probably, in a staticly typed language, be implemented with an object rather than a map.

It certainly does if your keys are not strings but objects.

using a statically typed language makes all these concerns moot

No, you can make exactly the same bug with a static type system. Structurally typed records are just that – structurally typed. If you add an extra field you never use, the type system doesn't care. You need further static analysis to catch that.

(Beside, Erlang ships with a decent static analyzer.)

Depends on your brand of static typing.

In fact, Erlang's records are something like this. They are tuples under the hood (with a first element being atom name of record "type"), and pre-processor translates matching properties by name to matching tuple elements in proper position. So, you can't made typo in this scenario - the code won't compile.

I.e., you declare:

    -record(foo, {bar = ?default_bar, baz = ?default_baz}).

And every time you write #foo{bar = 1} you get {foo, 1, ?default_baz} under the hood. Obviously, records are unusable as general-purpose dictionaries as they have fixed structure.

One big inconvenience with records is the fact that you have to type record's name every single time you have to do anything with it. And writing MyFoo#foo.bar is cumbersome, compared to MyFoo.bar in most other languages.

Another issue is that records exist only before pre-processing. Even compiler is unaware of member names, let alone the runtime. This makes introspection and live code operations (by connecting a shell to a running instance) quite inconvenient.

It'll still yell at you for typos, though. You can confuse positional with nominal, but you can't make invalid nominal statements.

Which is not at all to say that Erlang's tuple/record trick is anything but a clever trick. It is kind of neat to see how far you can go with just that, though.

The number of times I've had to type element(3, Record) (or whatever ordinal) for a filter/map, after manually -counting- the fields in the head of a list of records, because I didn't have the source with the record definition handy to rr() in my shell...

The abbrevation is not arbitrary and instead is very conventional among programmers. An arbitrary abbrevation would have been "ProDaBa" but no one abbrevates like that. The casing is also standardized: ProdDB in Python, prodDB in Java and (i believe) ProdDb in C#. Though that is beside the point because you still have to decide which letters to capitalize whether the name is long or short.

In Python, I would use `prod_db` as a dictionary key and not a name that looks like a class name. That said, I do agree that some very common abbreviations are okay in some contexts.

I prefer to counteract these potential bugs by locking the keys of a hash.

For eg. in Perl:

  use Hash::Util 'lock_keys';

  my %hash = (key1 => 'foo', key2 => 'bar', key3 => 'baz');  
  lock_keys %hash;

Now any attempts to lookup or amend a key that doesn't exist produces a runtime error...

  $hash{key1} = "FOO";   # updates fine
  $hash{key4} = "XXX";   # throws error

But now the culprit typo is typing -> when you meant :=

Maybe less likely, but if you've been writing a lot of code using -> and then in one case need := I can see it happening quite easily.

The system would complain loudly in an error message with a line number.

The problem with accidental key typos is that at their worst they are completely silent, and if the value you intend to replace was another valid value, finding the bug might not be easy.

That syntax for that purpose was totally stolen from Go. Nice to see the cross pollination going in both directions.

Go's := (short variable declaration) is closer to Erlang's => (introduce a new key) then it is to Erlang's := (update an existing key).

... and in that sense, Erlang is following existing practice better than Go did — := is "traditionally" an assignment operator, not a binding operator.

Reply on news.ycombinator.com