Live data from Hacker News

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

prateekcodes.dev

11–20 of 131 posts

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

#11
post #3

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.

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

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

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

#12

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

??? 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?

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

#13
post #3

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.

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

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

#14
post #3

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.

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

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

#15
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.

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

#16

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

??? 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?

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.

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

#17
post #14
post #3

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.

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

Thanks for the clarification! I have adjusted my wording.

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

#18

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

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.

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

#19
post #3

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.

just dont ask about unicode

Unicode support in Ruby has been great since the beginning.

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

#20
post #5
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.

All strings in python are immutable, as an example.
Post reply on HN