12 ms·
Ruby 3.4 frozen string literals: What Rails developers need to know
- deleted 1y ago[deleted]
- teddyh 1y agoTIL 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.
- llamataboot 1y agojust dont ask about unicode
- neallindsay 1y agoUnicode support in Ruby has been great since the beginning.
- yxhuvud 1y agoNo, it was not great during 1.x times. But it has been fairly good since 2.0
- WJW 1y agoSo for at least 12 years then. 2.0 was released in 2013.
- steveklabnik 1y agoIt'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://graysoftinc.com/character-encodings/bytes-and-characters-in-ruby-18 https://web.archive.org/web/20180331093051/http://graysoftin...
- llamataboot 1y agoright it was the python string transition i was talking about
- 0x457 1y agoOnly 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)
- thibaut_barrere 1y agoWe have mutable default arguments in Python (https://docs.python-guide.org/writing/gotchas/#mutable-default-arguments https://docs.python-guide.org/writing/gotchas/#mutable-defau...), by default too, though.
- teddyh 1y agoNot if they are strings, which is what this article is about.
- skywhopper 1y agoCool, good for you! I learned this in 2005.
- WJW 1y agoCool, good for you!
- tangus 1y agoStrings are going to keep being mutable by default. Only strings created by string literals won't be.
- teddyh 1y agoThanks for the clarification! I have adjusted my wording.
- __s 1y agoIn 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 1y agoI’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 1y agoSymbols have been GCed since CRuby 2.2 https://bugs.ruby-lang.org/issues/9634 https://bugs.ruby-lang.org/issues/9634
- corytheboyd 1y agoWell thats great, guess I have carried that baggage with me as misinformation for years now.
- hinkley 1y agoOne of the things I’ve said I would do and never did is create a set of test suites for as many facts about a language as I know and then run it for every new release to see what I need to unlearn. Most but not all of these were performance related. If it took a few days to run that’s fine. Major versions don’t come out that often.
- runeblaze 1y agoSame here. Turns out writing too much code for RPG Maker XP when young ruins one’s perception of Ruby forever
- zht 1y agodynamically created symbols have been garbage collected for almost 10 years
- dragonwriter 1y agoStrings 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.)
- ttoinou 1y agoIs 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 1y agoI 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.
- TkTech 1y agoAll strings in python are immutable, as an example.
- masklinn 1y agoAlso JavaScript.
- fud101 1y agoJava too. Rust has only 99 string types, some of those are immutable also.
- masklinn 1y agoIt does not really matter in rust anyway: literals are &’static str so naturally immutable and essentially free, and mutable strings require jumping hoops to share, so it’s hard to unwittingly have one mutate from under you.
- steveklabnik 1y ago
- llamataboot 1y agoWe 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
- hnlmorg 1y agoThis change doesn’t really compare to Py 2 vs 3
- skywhopper 1y ago??? 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 1y agoNot 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.
- neallindsay 1y agoRuby 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-released/ 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 1y agoI 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
- skywhopper 1y agoThis 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.
- _flux 1y agoBtw, 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).
- debugnik 1y agoNitpick: `bytes` is the read-write string, `Buffer` is the StringBuilder-like.
- _flux 1y agoOops, that's not a nitpick but a good correction :).
- dragonwriter 1y ago> 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.
- samgranieri 1y agoThis should hopefully go over easier than the keywords arguments transition.
- bitbckt 1y agoJust a bit under 15 years after we did this at Twitter.
- ksec 1y agoI would assume if Shopify and Github are on board then Rails is pretty well tested.
- jbverschoor 1y agoThe amount of misconceptions in this thread about mutable strings...
- ttoinou 1y agoLike what ?
- meisel 1y agoHow 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!
- shagie 1y agoThe 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 1y agoGot it, so this could not be extended to non-literal strings
- shagie 1y agoYou can freeze strings that are created at runtime. 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>'
- tangus 1y agoEven 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.
- baggy_trough 1y agoI 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.
- MallocVoidstar 1y agoIt's used as an example here: https://bugs.ruby-lang.org/issues/20205 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.
- prateekkish 1y agoHey 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.
- maximegarcia 1y agoWell 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)
- taeric 1y agoIt is sorta late to the party. Common Lisp has similar with regards to how lists are done. Specifically, it is not uncommon to make a static list like `'(1 2 3)`. Doing this, however, has implications on what operations you can do on the data elsewhere. I say sorta late to the party, as I think it is more than fair to say there was not much of a party that folks were interested in in the lisp world. :D
- drewcoo 1y ago
- hinkley 1y agoHow’s the htmlsafe trick going to work if strings are immmutable?
- byroot 1y agoFirst, 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.
- phendrenad2 1y agoHas 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.
- byroot 1y agoYes: https://bugs.ruby-lang.org/issues/20205#note-34 https://bugs.ruby-lang.org/issues/20205#note-34
- phendrenad2 1y agoAh excellent. Seems like a modest performance improvement.
- lcnPylGDnU4H9OF 1y agoI 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.
- temporallobe 1y agoWe 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.
- flufluflufluffy 1y agoThe 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!)
- byroot 1y agoThat's not quite how Ruby and similar languages like Python or JS work. Variables don't "contain" a string, they just point to objects on the heap. So: my_string = same_string = "Hello World" Here both variables are essentially pointers to a pre-existing object on the heap, and that object is immutable.
- flufluflufluffy 1y agoYeah it’s just the naming is weird. The string literal is not the object on the heap, it’s part of the program’s code itself, which was (assumedly) never mutable to begin with.
- dragonwriter 1y ago"Frozen string literals" doesn't mean that string literals are frozen, but that string literals (in the code) are reified as frozen strings. Obviously, the feature name is less fully expressive than the full sentence used to explain it, but that's a natural trade-off with wanting a usable name; it is evocative of the definition, not a restatement of it.
- chowells 1y agoIn ruby, "frozen" is a property of some values that makes them immutable. I mean, other than the part where you can mutably unfreeze objects of many classes. (At least you can't unfreeze strings.) This change makes string values that come from literals initially frozen. It has nothing to do with variable bindings.
- deleted 1y ago[deleted]
- dorianmariecom 1y agogreat post thanks
- dorianmariecom 1y agobtw byroot in this thread is a ruby code committer and rails core committer as well
- deleted 1y ago[deleted]
- ksec 1y agoMany comments about Python 2-3 moves. The problem with Python was that 2 to 3 offers little to no incentive. So I sometimes wonder why JIT isn't used as a motivation to move / remove features. Basically if you want JIT to work, your code has to be x ready or without feature x. So if you still want those performance improvements you will have to move forward.