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
    end
    
    # before, optim
    MY_STRING = "My String".freeze  # this does 2 allocations with 1 at init being GC quite early

    def my_method
      do_stuff_with(MY_STRING)
    end

    # after
    def my_method
      do_stuff_with("My String") # 1 allocation first time
    end

But this move also complicates strings manipulation in the sense of it will lean users toward immutable ops that tend to allocate a lot of strings.

    foo.upcase.reverse
    # VS
    bar = foo.dup
    bar.upcase!
    bar.reverse!

So now we have to be deliberate about it:

    my_string = +"My String" # it is not frozen

We have frozen string literals for quite a while now, enabled file by file with the "frozen_string_literal: true" comment and I've seen it as the recommended way by the community and the de-facto standard in most codebase I've seen. It is generally enforced by code quality tools like Rubocop.

So the mutable vs immutable is well known, and as it is part of the language, well, people should know the ins and outs.

I'm just a bit surprised that they devised this long path toward real frozen string literals, because it is already ongoing for years with the "frozen_string_literal: true" comment. Maybe to add proper warnings etc. in a way that does not "touch" code ? I prefer the explicit file by file comment. And for deps, well, the version bump of Ruby adding frozen string literals by default is quite a filter already.

Well, Ruby is well alive and it is what matters)

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 developed and starts to be similar to all others big programming languages ?

    'justastring' at: 6 put: $S; yourself

    'justaString' .

    #'justasymbol' at: 6 put: $S; yourself

    errorNoModification
        self error:  'symbols can not be modified.'

    a:='justastring'.
    b:='justastring'.
    a at: 6 put: $S.
    a, ' = ', b.
    'justaString = justaString' .

    | a b |
    a := 'justastring'.
    b := 'justastring'.
    a == b

    true .

  String

  &str

  &mut str

  &'static str 

  etc. 

TIL that Ruby has mutable strings, and (until the announced change) even had them mutable by default (and the change only affects literal strings; non-literal strings are still mutable). Python has always only ever had immutable strings.

This looks like a really thoughtful and well-planned transition, with years of opt-in warnings followed by years of opt-out warnings before the actual cutover. I’m constantly impressed with the methodical approach of the Ruby team to constantly improving the language in ways that disrupt their users as little as possible.

We implemented this recently on a Rails project as part of a Rubocop integration. It actually uncovered a lot of subtle bugs, though I will say that the Ruby language lends itself to buggy code. Thankfully we have sophisticated tooling these days that (mostly) mitigates this.

Btw, OCaml also transitioned from read-write Strings to read-only Strings, and Buffer to be that read-write string. It was introduced in 4.02 released September 2014.

I recall it was a bit bumpy, but not all that rough in the end. I suppose static type checking helps here to find all the ways how it could be used. There was a switch to allow running old code (to make strings and buffers interchangeable).

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!

    fooLit = "foo"
    fooVar = "f".concat("o").concat("o")

    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 #<Class:#<String:0x000000015807ec58>>: "foo" (FrozenError)
     from (irb):5:in '<main>'
     from <internal:kernel>: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 '<top (required)>'
     from /opt/homebrew/opt/ruby/bin/irb:25:in 'Kernel#load'
     from /opt/homebrew/opt/ruby/bin/irb:25:in '<main>'

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

The phrase “Frozen String Literals” is kind of weird to me. When I assign a string literal to a variable, I do not think of the variable itself as a “string literal.” That phrase is for the literal characters in between quotes in the code, which by definition are already “frozen.” They’re a static part of the code itself. This change makes it so that you cannot mutate a variable which was initialized using a string literal. (if I understand correctly!)

   my_string = same_string = "Hello World"

I often do something like

  SUB_ME = ':sub_me'.freeze
  def my_method(method_argument)
    foo = 'foo_:sub_me'
    foo.sub!(SUB_ME, method_argument)
    foo
  end

which, without `# frozen_string_literal: true`, I believe allocates a string when the application loads (it sounds like it might be 2) and another string at runtime and then mutate that.

That seems like it's better than doing

  # frozen_string_literal: true
  FOO = 'foo_:sub_me'
  SUB_ME = ':sub_me'
  def my_method(method_argument)
    FOO.sub(SUB_ME, method_argument)
  end

because that will allocate the frozen string to `FOO` when the application loads, then make a copy of it to `foo` at runtime, then mutate that copy. That means two strings that never leave memory (FOO, SUB_ME) and one that has to be GCed (return value) instead of just one that never leaves memory (SUB_ME) and one that has to be GCed (foo/return value).

This is true in particular when FOO is only used in `my_method`. If it's also used in `my_other_method` and it logically makes sense for both methods to use the same base string, then it's beneficial to use the wider-scope constant.

(The reason this seems reasonable in an application is that the method defines the string, mutates it, and sends it along, which primarily works because I work on a small team. Ostensibly it should send a frozen string, though I rarely do that in practice because my rule is don't mutate a string outside the context in which it was defined, and that seems sensible enough.)

Am I mistaken and/or is there another, perhaps more common pattern that I'm not thinking about that makes this desirable? Presumably I can just add # frozen_string_literal: false to my files if I want so this isn't a complaint. I'm just curious to know the reasoning since it is not obvious to me.