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

Posted by thomas_witt 7/6/2025

Ruby 3.4 frozen string literals: What Rails developers need to know(www.prateekcodes.dev)

237 points | 127 commentspage 3

hinkley 7/9/2025|

How’s the htmlsafe trick going to work if strings are immmutable?

byroot 7/9/2025|

First, only literal strings are concerned. Second, Rails's `String#html_safe` method's return value is a new instance, it doesn't mutate the receiver in place.

llamataboot 7/9/2025||

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 7/9/2025||

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 7/9/2025||

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 7/9/2025|||

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

skywhopper 7/9/2025|||

??? 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 7/9/2025||

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.

hnlmorg 7/9/2025|||

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

byroot 7/9/2025||

Even if you have an incompatible codebase that you don't wish to convert, you'll be able to set `RUBYOPT="--disable-frozen-string-literal"` so it keeps running.

And since that flag really doesn't require lots of work in the VM, it's likely to be kept around pretty much forever.

dorianmariecom 7/9/2025|

great post thanks