[Pamar]

From the Rationale paragraph:

However, JSON knows only about lists and maps. There is no concept of object types or classes. This means that it is not easy to encode arbitrary objects, and some of the possible solutions are quite verbose (Encoding the type or class as a property and/or adding an indirection to encode the object's contents).

Adding a symbol (globally unique string) primitive type is a very useful addition: because symbols help to represent constant values in a compact and fast yet readable way, and because symbols allow simpler and more readable map keys.

[dkersten]

As a clojure guy, I use EDN for the same reasons that STON exists (but of course EDN plays beautifully with clojure)

[throwanem]

This is very true! What a shame the no doubt very clever people who specified ES6 failed to read it, because if they had, I can't imagine that ES6 "symbols" would be so bizarrely broken.

[thomasfoster96]

> I can't imagine that ES6 "symbols" would be so bizarrely broken.

In what way are ES6 “symbols” broken? (genuinely interested, I haven’t really used symbols before)

[parenthephobia]

They're not like what are called symbols in any other language.

An ES6 symbol is a unique object with an optional name. They can be used as property names, like strings, which means that code can add new properties to objects without worrying about name collisions. Two symbols are distinct objects regardless of name: Symbol("foo") is never the same symbol as Symbol("foo").

Symbols as used in other languages (sometimes also called atoms) are effectively unique instances of strings. They chiefly serve the opposite purpose of ES6 symbols, which is being able to refer to the same object by name in different parts of code, even across executions of the program, or across distributed systems. i.e. :foo is always the same symbol as :foo.

They're (often) more efficient than simple strings because :foo and :foo will always reference the same object in a given instance of the program, so they can be compared by address rather than character-by-character.

Some languages with symbols have a function, often called gensym, for generating a symbol with a unique name, for when you need to support ES6's use case. e.g. Lisp and Prolog.

[WorldMaker]

Given ES2016's intended goal to remove a lot of the global interconnected nature of the language (let/const over classic var; module scopes), it seems clear why ES2016 "over-corrected" and only supports the gensym-style unique symbols and exporting them at the module level if they need to be reused. (From whence known symbols like Symbol.iterator exist.)

I've seen strawman proposals for ES to also support some form of a global symbol namespace, but after debugging much of the legacy of JS global-happy code and order-of-script-tags bugs I, for one, am happy that none of those strawman proposals are currently favored by the committee.

[v413]

There are global symbols. You use Symbol.for() to either create or retrieve them. E.g. Symbol.for('hello') is available globally through the global registry. It should be noted that an already existing symbol e.g. Symbol('hello') is not the same as Symbol.for('hello') while Symbol.for('hello') === Symbol.for('hello')

[WorldMaker]

Thanks, I had forgot that had made it in after all.