Actually it is part of the argument. I watched the video linked to the post. The speaker says that symbols and strings are converging. Frozen strings are symbol like and symbol GC made symbols string like. Symbols were a performance optimization and we are close not to need it anymore.

I'm not sure there isn't more about symbols than that but I'll think about it the next time I'll write some Ruby. I'll pretend I have only strings and see what happens. One thing for sure: we'd need a syntactical shortcut because having to type "string".freeze everytime is unbearable. If the right shortcut is :string or the lispy 'string, I don't know but if we need it symbols are fine even if symbol.class could end up being String.

I just read the article so it sounds like the author is punting on symbols in the direction of the video. Before responding now I went back and watched the video.

As far as the difference between "string".freeze and :string; the symbol will resolve to the same object_id every time across systems and processes. If you spin up irb and type :foo.object_id you will see 1092508. Now one way this is commonly used in Ruby is when we use Object#send. We pass a symbol in place of the function name as the first argument and internally this is used as a system optimization to lookup the function that is being called dynamically.

Now I haven't been knee deep in the code of any of the Rack web servers, but I would imagine that something like Puma which is built for concurrency and multi-threading could take advantage of this behavior as well for some shared process to enable spinning up lighter weight additional processes or threads thus leading to lower memory consumption on your web server and the ability to handle more traffic on the same hardware.

Erik is right in saying that strings and symbols are "converging"; they have not yet converged however. At the point at which strings converge to symbols in the sense that both resolve to the same object across systems, then what we have left is symbols and so it is not symbols that have been killed, but rather strings supplanted by symbols. If instead we go the direction of saying memory and performance don't matter so let's punt on that whole symbols are immutable thing I think we are giving up too much.

I use Ruby because the high level abstraction is great and saves me developer cycles, but I also want it to eek out as much performance as possible. Honestly in general I'm tired of hearing the argument that X should die now because it is a performance hack. Some performance hacks are good.

(For reference: In the video he discusses symbols vs freezing strings from 22:00 to 25:07)

> the symbol will resolve to the same object_id every time across systems and processes. If you spin up irb and type :foo.object_id you will see 1092508.

object_id for symbols is not consistent across processes.

   % ruby -e "p :foo.object_id"
   396968
   % ruby -e "p :bar.object_id"
   396968
   % ruby -e ":bar; p :foo.object_id"
   397128

You're getting 1092508 consistently not because it's :foo but because it's the next object_id available for a symbol after all the ones created during IRB startup.

Well dang... that is interesting and not what I expected. So from this I can infer that it also changes if a symbol is garbage collected now. So has the implementation of Object.send changed in Ruby 2.2+ as well? The latest copy of the code I have looked at is 1.9.3.

Yes, symbols that are garbage collected will get new object IDs if they appear again.

https://gist.github.com/mboeh/83338a4e3a6a77689e22