3 ms·
> This is silly. Oh my bad, great counterpoint. > The semantics are entirely different! They're not. A symbol is an arbitrary identifier, which can be used t
by masklinn 11mo ago
> This is silly.
Oh my bad, great counterpoint.
> The semantics are entirely different!
They're not. A symbol is an arbitrary identifier, which can be used to point to system elements (e.g. classes, methods, etc...). These are all things you can do just fine with immutable interned strings. Which is exactly what languages which have immutable interned strings do.
You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby, so it needs symbols. Both things it inherited from all of Perl, Smalltalk, and Lisp.
- byroot 11mo agoRuby always had immutable (frozen) strings, so no, this never was a reason for Symbols existence.
- dragonwriter 11mo agoThey aren't interned frozen strings (unless they were symbols; String#intern was, and still is, an alias for String#to_sym, and String#freeze did not and does not imply String#intern or String#to_sym), and it also (even for literals) took an extra step to either freeze or intern them prior to Ruby 2.3 introducing the "# frozen_string_literal: true" file-level option (and Ruby 3.4 making it unnecessary because it is on by default.) Amusingly, string literals interned by default in 3.4 or because of the setting in earlier >2.3 Rubies are still (despite being interned) Strings, while Strings interned with String#intern are Symbols.
- byroot 11mo ago> They aren't interned frozen strings Doesn't matter. The parent claim was: > You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby From day one it was possible to freeze strings used in metaprograming. I mean Ruby Hashes do that to strings keys. > Ruby 3.4 making it unnecessary because it is on by default. That's incorrect: https://byroot.github.io/ruby/performance/2025/10/28/string-literals.html https://byroot.github.io/ruby/performance/2025/10/28/string-...