5 ms·

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

by happyrock 4y ago

revskill 4y ago
Is it for performant reason ?
- onei 4y ago
  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.
  - justincormack 4y ago
    Lua (and some other languages) intern strings, so all strings that are the same point to the same string instance. This gives the same benefits (plus string equality is just pointer equality) without a different type.
  - pawelduda 4y ago
    There is a caveat in older Ruby versions that they aren't garbage collected, so they shouldn't be used for things like user input. Not a problem since 2.2 though.
- progval 4y ago
  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.
  - masklinn 4y ago
    > 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. All of those strings will be interned, and can thus be compared by identity. Which is an integer comparison.
masklinn 4y ago
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 4y ago
  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 4y ago
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.
- masklinn 4y ago
  > 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.
- jnordwick 4y ago
  https://code.kx.com/q/basics/enumerations/ https://code.kx.com/q/basics/enumerations/ i miss k
amalgamated_inc 4y ago
Both Lisp and Erlang have them, so they're much older than Ruby.
- andrewflnr 4y ago
  Presumably Erlang inherited them from Prolog, too.
  - amalgamated_inc 4y ago
    I don't remember Prolog much, but since Erlang inherited very much, you're probably right.
timmaxw 4y ago
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.
- sanderjd 4y ago
  Always serialize the keys back to symbols.
- lamontcg 4y ago
  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.
lispm 4y ago
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.
zffr 4y ago
In languages that are statically typed and support enums, symbols are not necessary IMO.
still_grokking 4y ago
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.

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

revskill 4y ago

Is it for performant reason ?

onei 4y ago
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.
- justincormack 4y ago
  Lua (and some other languages) intern strings, so all strings that are the same point to the same string instance. This gives the same benefits (plus string equality is just pointer equality) without a different type.
- pawelduda 4y ago
  There is a caveat in older Ruby versions that they aren't garbage collected, so they shouldn't be used for things like user input. Not a problem since 2.2 though.
progval 4y ago
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.
- masklinn 4y ago
  > 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. All of those strings will be interned, and can thus be compared by identity. Which is an integer comparison.

masklinn 4y ago

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 4y ago
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 4y ago

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.

masklinn 4y ago
> 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.
jnordwick 4y ago
https://code.kx.com/q/basics/enumerations/ https://code.kx.com/q/basics/enumerations/ i miss k

amalgamated_inc 4y ago

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

andrewflnr 4y ago
Presumably Erlang inherited them from Prolog, too.
- amalgamated_inc 4y ago
  I don't remember Prolog much, but since Erlang inherited very much, you're probably right.

timmaxw 4y ago

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.

sanderjd 4y ago
Always serialize the keys back to symbols.
lamontcg 4y ago
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.

lispm 4y ago

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.

zffr 4y ago

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

still_grokking 4y ago

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.