Ruby 3.4 frozen string literals: What Rails developers need to know

Post by ttoinou » Wed, Jul 09, 2025, 3:43 PM UTC

jbverschoor wrote: post #35

The amount of misconceptions in this thread about mutable strings...

Post by fiddlerwoaroof » Wed, Jul 09, 2025, 4:05 PM UTC

OskarS wrote: post #5

ttoinou wrote: post #4

Is it the future path of any successful JIT / dynamic typed / scripting language to realize they needed all optimizations from compiled / statically typed / lower level languages ? Would Ruby be as successful if they had all those complicated features right from the start ? Or do all languages start from a nice simple clean slate tabula rasa to get developers hooked, until the language is enough famous to get well de…

I would actually say it’s the opposite in this case: it’s extremely common in scripting languages for strings to be immutable, mutable strings are usually only available in lower level languages. I’m very surprised Ruby had this feature at all.

Post by shagie » Wed, Jul 09, 2025, 4:39 PM UTC

meisel wrote: post #57

shagie wrote: post #42

Earlier quoted context omitted.

The literals would be identified at parse time. fooLit = "foo" fooVar = "f".concat("o").concat("o") This would have fooLit be frozen at parse time. In this situation there would be "foo", "f", and "o" as frozen strings; and fooLit and fooVar would be two different strings since fooVar was created at runtime. Creating a string that happens to be present in the frozen strings wouldn't create a new one.

Got it, so this could not be extended to non-literal strings

    irb(main):001> str = "f".concat("o").concat("o")
    => "foo"
    irb(main):002> str.frozen?
    => false
    irb(main):003> str.freeze
    => "foo"
    irb(main):004> str.frozen?
    => true
    irb(main):005> str = str.concat("bar")
    (irb):5:in 'String#concat': can't modify frozen #>: "foo" (FrozenError)
     from (irb):5:in ''
     from :168:in 'Kernel#loop'
     from /opt/homebrew/Cellar/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/irb-1.14.3/exe/irb:9:in ''
     from /opt/homebrew/opt/ruby/bin/irb:25:in 'Kernel#load'
     from /opt/homebrew/opt/ruby/bin/irb:25:in ''

Post by hinkley » Wed, Jul 09, 2025, 4:56 PM UTC

tangus wrote: post #43

meisel wrote: post #40

How does this work under the hood? Does Ruby keep a giant map of all strings in the application to check new strings against to see if it can dedupe? Does it keep a reference count to each unique string that requires a set lookup to update on each string instance’s deallocation? Set lookups in a giant set can be pretty expensive!

Even if it didn't dedupe strings, mutable string literals means that it has to create a new string every time it encounters a literal in run time. If you have a literal string in a method, every time you call the method a new string is created. If you have one inside a loop, every iteration a new string is created. You get the idea. With immutable strings literals, string literals can be reused.

Post by taeric » Wed, Jul 09, 2025, 5:16 PM UTC

maximegarcia wrote: post #49

Well it is not quite a mutable vs immutable strings war, nor Ruby being late to the party or something like that. The move is so we can avoid allocating a string each we declare and use it since it will be frozen by default. It is a big optimization for GC mainly. Before we had to do such optimization by hand if we intend not to modify it: # before def my_method do_stuff_with("My String") # 1 allocation at each call…