Many bad things originate from the rails ecosystem. (Arguably some good too, but I am very pessimistic ever since shopify's recent powermove and DHH side-line commenting off-the-fence while being on shopify's board.)

It no longer make sense today, and any new use of it is a smell.

> If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.

This is terrible. This is the exact opposite of what Ruby is trying to achieve: developer happiness. You basically implement "symbol is a string" for hashes (aka HashWithIndifferentAccess).

> But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default.

This is not the case. If you omit "# frozen_string_literal: true", the strings are mutable, in all versions of Ruby, even in Ruby 4.0, which will be released on 25 Dec.

> But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.

If it walks like a duck and quacks like a duck... Who cares? What's the difference it makes for you whether symbols and string are interchangeable? Show me one valid use-case where having symbols and strings being different (user[:name] vs user["name"], or attr_reader "name") is useful.

An irrelevant implementation detail. Interned strings are also stored globally, and depending on implementations interned strings may or may not be subject to memory reclaiming.

> Ruby does not care for efficiency, so there is no point to argue for symbols vs string performance

Which is why Ruby's having symbols is associated with mutable strings, not inefficient strings.

And there's a gulf between not caring too much about efficiency and strings being a linked list of integers, which is what they are in Erlang.

Symbols existed entirely for performance reasons and were once never GC'd: this is absolutely Ruby "car[ing] for efficiency."

Today, Ruby's Symbol is GC'd (and is much closer to 'String' in practicality) but still has enormous impacts on performance.

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.

Sure. They are just less efficient as hash keys.

Although now the distinction blurs with frozen strings (and the string literals being frozen by default switch).

It's completely true of lisp. Lisp strings are generally mutable (although literal strings may be interned and non-mutable, or even worse mutation of literal strings may be UB). Same for Smalltalk.

You can certainly associate such things with an integer: e.g. value_cell[42], plist[42].

But those associations are part of the "symbolness", not just the 42.

Integers are not suitable symbols in some ways: they have a security problem.

Real symbols can be used for sandboxing: if you don't already hold the symbol, you have no way to get it.

This won't happen for integers. Especially not reasonably small integers.

What do I mean that if you don't already have a symbol, you have no way to get it? If the symbol is interned, you can intern it, right?

Not if there is a symbol package system, and you don't have access to the package in which the symbol is interned.

Now you might say, since objects are typically represented as pointers, aren't those a kind of integer anyway? Yes they are, but they are different type which doesn't support arithmetic; we can restrict programs from calculating arbitrary pointers, but we can't restrict programs from calculating arbitrary integers.

Even if we have escape hatches for converting an integer to a pointer, or other security/safety bypassng mechanisms, those escape hatches have an API which is identified by symbols, which we can exclude from the sandbox.

String can be interned in Ruby, but it’s always possible for an equal string that is not interned to also exist. Hence interned strings can’t benefit from the same optimization than symbols.

You can first compare them by pointer, but on a mismatch you have to fallback to comparing content. Same for the hashcode, you have to hash the content.

If it was up to me I'd get rid of them, but I know I have an unpopular opinion and it's really only a thought experiment.