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

63 comments

·July 6, 2025

maximegarcia

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)

ttoinou

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 ?

OskarS

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.

fiddlerwoaroof

Common Lisp and Smalltalk have mutable strings, I think. So it’s not too surprising that ruby does too, since it was pretty heavily influenced by these languages.

wavemode

Even in C, string literals are immutable, and mutating them is undefined behavior.

ttoinou

But in the syntax of scripting language its very easy to create a new string from the old string, destroy old string, replace variable by new string. Which appears mutable from the point of view of the developer

TkTech

All strings in python are immutable, as an example.

masklinn

Also JavaScript.

superjan

It’s true that many languages have immutable strings, but for a web-focused scripting language it makes sense to default to mutable strings. I think the comment is about that you now need to choose mutable vs immutable, and that is framed as a consequence of broader adoption. Which is a development I have also seen before.

empthought

> for a web-focused scripting language it makes sense to default to mutable strings

Why do you say that? I would say the opposite.

ttoinou

Exactly thank you. Not sure why you’re downvoted

bastawhiz

> all optimizations from compiled / statically typed / lower level languages

Mutable strings are totally possible (and not even especially hard) in compiled, statically typed, and lower-level languages. They're just not especially performant, and are sometimes a footgun.

> all those complicated features right from the start

Arguably, mutable strings are the more complicated feature. Removing them by default simplifies the language, or at least forces you to go out of your way to find the complexity.

ttoinou

Its not about possible / not possible its about what the language does by default and how language syntax changes to switch between different variants of strings

IshKebab

> They're just not especially performant

What? Mutable strings are more performant generally. Sometimes immutability allows you to use high level algorithms that provide better performance, but most code doesn't take advantage of that.

vnorilo

Not in general. Immutable strings can be deduplicated, leading to a different performance tradeoff that is often quite good. This is mentioned in TFA.

throwawaymaths

erlang is jitted and dynamic and all terms are immutable.

teddyh

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.

__s

In Ruby you tend to use :symbol for small immutable strings

<< is inplace append operator for strings/arrays, while + is used to make copy. So += will make new string & rebind variable

corytheboyd

I’ll just kill the comment. It said Symbol isn’t garbage collected. It has been since 2.2 and I wasn’t aware. Sorry.

Good reminder that anyone can go on the internet, just say stuff, and be wrong.

jashmatthews

Symbols have been GCed since CRuby 2.2 https://bugs.ruby-lang.org/issues/9634

zht

dynamically created symbols have been garbage collected for almost 10 years

thibaut_barrere

We have mutable default arguments in Python (https://docs.python-guide.org/writing/gotchas/#mutable-defau...), by default too, though.

teddyh

Not if they are strings, which is what this article is about.

dragonwriter

Strings will still be mutable by default after the change which only makes string literals always frozen (which has been a file-level opt-in for a while.)

tangus

Strings are going to keep being mutable by default. Only strings created by string literals won't be.

teddyh

Thanks for the clarification! I have adjusted my wording.

llamataboot

just dont ask about unicode

neallindsay

Unicode support in Ruby has been great since the beginning.

steveklabnik

It's a bit weirder than that, in my opinion. Ruby didn't really gain "unicode support" in the sense we mean it today until 1.9.

Before that, Ruby did "support encodings" in a sense, but a lot of the APIs were byte oriented. It was awkward in general.

https://web.archive.org/web/20180331093051/http://graysoftin...

yxhuvud

No, it was not great during 1.x times. But it has been fairly good since 2.0

llamataboot

right it was the python string transition i was talking about

skywhopper

Cool, good for you! I learned this in 2005.

jbverschoor

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

ttoinou

Like what ?

meisel

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!

tangus

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.

shagie

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.

meisel

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

masklinn

The way it works in Python is that string literals are stored in a constant slot of their parent object, so at runtime the VM just returns the value at that index.

Though since Ruby already has symbols which act as immutable interned strings, frozen literals might just piggyback on that, with frozen strings being symbols under the hood.

_flux

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).

dragonwriter

> Btw, OCaml also transitioned from read-write Strings to read-only Strings

Ruby is not doing that, it's transitioning from mutable strings that can be frozen with no special treatment of literals (unless you opt-in to literals being frozen on per file basis) to mutable strings with all string literals frozen.

debugnik

Nitpick: `bytes` is the read-write string, `Buffer` is the StringBuilder-like.

bitbckt

Just a bit under 15 years after we did this at Twitter.

ksec

I would assume if Shopify and Github are on board then Rails is pretty well tested.

skywhopper

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.

samgranieri

This should hopefully go over easier than the keywords arguments transition.

llamataboot

We learned nothing from Python 2->3

An obviously good change, actually massive performance improvements not hard to implement but its still gonna be such a headache and dependency hell

neallindsay

Ruby has been extremely slow and deliberate in rolling out frozen string literals. They added a magic comment to opt in to them on a per-file basis all the way back in Ruby 2.3—almost a decade ago.

https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-rele...

Most linting setups I've seen since then have required this line. I don’t expect many libraries to run afoul of this, and this warning setting will make finding them easy and safe. This will be nothing like the headache Python users faced transitioning to 3.

llamataboot

I hope this is corect - i do agree it has been a long and slow migration path and migrating is fairly easy - migrating python 2 to 3 code was fairly easy as well anyone could do it in their codebase, it remains a big deal and possibly very impactful to make such breaking changes to the behavior of primitives in mature ecosystems. How many gems does the average rails app have, okay they all need to be updated and they sohld be being updated for other reasons, I remain skeptical of how smooth the change is going to be over all ecosystem wise but time will tell.

I agree it has been a well advertised and loudly migration path and timeframe for it

arp242

Most of the problems in Python 3 were the string encoding changes. It was very pervasive, fixing things was often not so straight-forward, and writing programs that worked well with Python 2 and 3 was possible but somewhat difficult and error-prone.

The rest of the changes were a bit annoying but mostly boring; some things could have been done better here too, but the string encoding thing was the main issue that caused people to hold on to Python 2 for a long time.

The frozen string literal changes are nothing like it. It's been "good practise" to do this for years, on errors fixing things is trivial, there is a long migration path, and AFAIK there are no plans to remove "frozen_string_literal: false". It's just a change in the default from false to true, not a change in features.

"Learning lessons" doesn't mean "never do anything like this ever again". You're the one who failed to learn from Python 3, by simply saying "language change bad" without deeper understanding of what went wrong with Python 3, and how to do things better. Other languages like Go also make incompatible changes to the language, but do so in a way that learned the lessons from Python 3 (which is why you're not seeing people complain about it).

hnlmorg

This change doesn’t really compare to Py 2 vs 3

skywhopper

??? This is nothing like the Python transition. In Python there were two incompatible language versions side by side for years that made it really hard on library maintainers. Ruby is giving a 7-8 year transition period before this even hits, with years of warnings built-in to the plan. What more would you have them do?

lloeki

Not to mention that in addition to the opt-in warning that came with 3.4, if you've been using any reasonable linter such as Rubocop for the past 10ish years then you're already being yelled at for lack of `# frozen_string_literal: true` magic comment.

null

[deleted]

HN

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

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