[happyrock]

I have long wondered why Ruby's symbols aren't in every language.

[masklinn]

Because in most languages they're not useful. Symbols are solutions to problems, some of which are:

1. mutable strings (ruby)

2. and / or expensive strings (erlang, also non-global)

If you have immutable "dense" strings and interning, and you automatically intern program symbols (identifiers, string literals, etc...) then symbols give you very little.

And then there's the slightly brain damaged like javascript, where symbols are basically a way to get some level of namespacing to work around the dark years of ubiquitous ad-hoc expansions so you're completely stuck unable to add new program symbols to existing types because you could break any page out there doing something stupid.

[sanderjd]

As the article covers, they are nice syntactically, regardless of those performance considerations. They fill a niche that in my experience actually turns out to be more common than string literals (though less common than strings as actual textual data).

I haven't written ruby (or any lisps) for awhile, and I miss symbols.

[RodgerTheGreat]

They exist in K/Q. A single-word identifier-shaped symbol begins with a backtick, or a multi-word symbol can be created with a backtick and double quotes. A sequence of symbols is a vector literal, and is stored compactly. For example:

    `apple
    `"cherry pie"
    `one`two`three

Many languages will intern string literals implicitly, or allow a programmer to explicitly intern a string; for example Java's "String.intern()".

The problem with string interning, especially for strings constructed at runtime, is that for the interning pool to be efficient it is very desirable for it to be append-only, and non-relocatable. A long-running program which generates new interned strings on the fly risks exhausting this pool or system memory.

[jnordwick]

https://code.kx.com/q/basics/enumerations/

i miss k

[masklinn]

> A long-running program which generates new interned strings on the fly risks exhausting this pool or system memory.

So does a long-running program which generates new symbols on the fly.

[lispm]

Ruby symbols are similar to keyword symbols in Common Lisp. There a keyword symbol is a symbol which evaluates to itself:

    CL-USER 69 > :a-keyword-symbol
    :A-KEYWORD-SYMBOL

Keywords with a similar name are identical:

    CL-USER 70 > (eq :a-keyword-symbol :a-keyword-symbol)
    T

One can't set keyword symbols to another value:

    CL-USER 71 > (setf :a-keyword-symbol 3)

    Error: Cannot setq :A-KEYWORD-SYMBOL -- it is a keyword.

They have certain features of normal symbols, like a property-list with keyword/value pairs.

[amalgamated_inc]

Both Lisp and Erlang have them, so they're much older than Ruby.

[andrewflnr]

Presumably Erlang inherited them from Prolog, too.

[timmaxw]

Personally, I found Ruby's symbols to be a source of bugs because they can easily get mixed up with strings. The article gives the example of dict[:employee_id]. But what happens if you serialize "dict" as JSON, then parse it again? The symbol :employee_id will be silently converted to "employee_id", which is treated as a different dict key from :employee_id. I found it was easy to lose track of whether a given dictionary is using the "keys are symbols" or the "keys are strings" convention, especially in larger codebases.

[lamontcg]

Yeah symbols are terrible and they lead to using Mashes or "Hashes with indifferent access" to attempt to allow both syntax. This helps with round tripping to JSON and back and getting consistent access either way, but values are still not converted. And values shouldn't be symbolized from JSON which means round tripping through JSON typically converts symbols into strings.

It would be a lot easier if symbols had been just syntactic sugar for immutable frozen strings so that :foo == "foo".freeze == "foo" would be true.

And under the covers these days there is very little difference. It used to be that symbols were immutable and not garbage collected and fast. And that strings were mutable and garbage collected and slow.

These days symbols are immutable and garbage collected and fast and frozen strings are immutable and garbage collected and fast (and short mutable strings are even pretty fast).

Symbols as a totally different universe from Strings I would consider to be an antipattern in language design. They should just be syntactic sugar for frozen strings if your language doesn't already have frozen strings by default.

[sanderjd]

Always serialize the keys back to symbols.

[zffr]

In languages that are statically typed and support enums, symbols are not necessary IMO.

[still_grokking]

As a side note: Symbols got just removed from Scala 3. They were there quite useless an can be replaced with strings without any downsides.

[revskill]

Is it for performant reason ?

[onei]

Symbols in Ruby are meant to be more performant that strings iirc. If I have symbol :a, then it's allocated once regardless of how many time it appears. As opposed to "a" which is reallocated every time.

I guess it's similar to Python having a single instance of small integers. PlayStation also experimented with caching small floats which gave them some perf improvements too, but I think wasn't as performant in all cases.

[progval]

Symbols can even improve performance. Replace them with integers at compile time like a global enum, and so the runtime only needs to compare integers instead of potentially lengthy (especially if UTF-16) strings.