Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

prateekcodes.dev

Post reply on HN
Print view View original

71–80 of 131 posts

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

#71

Post by lcnPylGDnU4H9OF »

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.

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

#72

Post by temporallobe »

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.

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

#73

Post by SomeoneOnTheWeb »

ttoinou wrote: post #61
OskarS wrote: post #5

Earlier quoted context omitted.

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.

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

Can't you do the exact same in compiled languages e.g. C or Rust?

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

#74

Post by prateekkish »

MallocVoidstar wrote: post #56
baggy_trough wrote: post #47

I wonder what the basis is for the description of the 3.7 / 4 ruby releases is. I haven't seen this transition plan with version numbers described outside of this blog post.

It's used as an example here: https://bugs.ruby-lang.org/issues/20205 But not actually stated it's the plan. I'd bet whatever LLM wrote the article took it as a stronger statement than it is.

Hey there. I wrote the article. While I know the version numbers aren’t concrete, I added the proposal anyways as a way for readers to visualise what the maintainers had in mind. Since we’re only at 3.4 with 3.5 in preview, it can’t be claimed concretely what the future holds. I just didn’t make that super obvious in the post.

I had to explain the same reasoning in Reddit the other day. Perhaps it’s time to take this as a feedback and update the blog.

Btw I just asked gpt to write an article on the same topic, with a reference to the Ruby issues page. And it DID NOT add the future proposal part. So LLMs are definitely smarter than me.

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

#75

Post by 0x457 »

neallindsay wrote: post #19
llamataboot wrote: post #8

Earlier quoted context omitted.

just dont ask about unicode

Unicode support in Ruby has been great since the beginning.

Only if you count 1.9.2 as the beginning. What is being talked about is Unicode by default and maybe Unicode tooling (i.e. can correctly iterate over emojis and not just bytes)

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

#76

Post by superjan »

empthought wrote: post #28
superjan wrote: post #24

Earlier quoted context omitted.

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.

> for a web-focused scripting language it makes sense to default to mutable strings Why do you say that? I would say the opposite.

Because there’ll likely be a lot of string concatenation in a language whose job is to output HTML. Adding a single char to a 1k string will require allocating a modified copy, in mutable strings it’s just appending in a preallocated buffer.

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

#77

Post by byroot »

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…

> I'm just a bit surprised that they devised this long path

The original plan was to make the breaking change in 3.0, but that plan was canceled because it broke too much code all at once.

Hence why I proposed this multi-step plan to ease the transition.

See the discussion on the tracker if you are curious: https://bugs.ruby-lang.org/issues/20205

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

#78

Post by byroot »

phendrenad2 wrote: post #69

Has anyone actually benchmarked the use of frozen string literals? I feel like this is one of those micro-optimizations that everyone does, but they're probably accomplishing a diminishingly small performance improvement, while making the codebase less readable. On net, a negative.

Yes: https://bugs.ruby-lang.org/issues/20205#note-34

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

#80

Post by flufluflufluffy »

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!)
Post reply on HN