51–60 of 131 posts
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.
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).
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.
Earlier quoted context omitted.
Not in general. Immutable strings can be deduplicated, leading to a different performance tradeoff that is often quite good. This is mentioned in TFA.
Mutable strings can be duplicated too. You can use reference counting, or borrow checking in Rust.
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 findi…
I agree it has been a well advertised and loudly migration path and timeframe for it
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.
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.
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!
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.
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.
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…
> 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 simplifie…
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.
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.