btw byroot in this thread is a ruby code committer and rails core committer as well
Ruby 3.4 frozen string literals: What Rails developers need to know
91–100 of 131 posts
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#92Is 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…
erlang is jitted and dynamic and all terms are immutable.
A lot of functional programming languages are like this and that can make them not efficient
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#93Earlier 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.
> for a web-focused scripting language
Ruby is not a web focused scripting language.
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#94Earlier quoted context omitted.
Java too. Rust has only 99 string types, some of those are immutable also.
Rust the language has one string type: &str The standard library also has String, CString, CStr, OsString, and OsStr. The latter four are for niche situations. 99.9% of the time, it's similar to Java: &str is Java's String, String is Java's StringBuffer/StringBuilder.
I would add Path and PathBuf to that list.
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#95Earlier quoted context omitted.
Also JavaScript.
Java too. Rust has only 99 string types, some of those are immutable also.
All of those languages except JavaScript have mutable strings; they just have different names and API shapes. Python has io.StringIO, Java has StringBuilder, Rust has String. (JavaScript has less need for this because JavaScript strings are ropes in most widely used implementations, reducing the overhead of concatenation, though the language spec doesn't require this.)
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#96TIL 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.
Cool, good for you!
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#97Earlier quoted context omitted.
Rust the language has one string type: &str The standard library also has String, CString, CStr, OsString, and OsStr. The latter four are for niche situations. 99.9% of the time, it's similar to Java: &str is Java's String, String is Java's StringBuffer/StringBuilder.
I would add Path and PathBuf to that list.
Paths are not strings, that's the whole point!
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#98Earlier quoted context omitted.
> 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? 1. Strings have a flag (FL_FREEZE) that are set when the string is frozen. This is checked whenever a string would be mutated, to prevent it. 2. There is an interned string table for frozen strings. > Does it keep a reference count to each unique string that requires…
There's no need for ref counting, since Ruby has a mark & sweep GC. The interned string table uses weak references. Any string added to the interned string tables has the `FL_FSTR` flag set to it, and when a string a freed, if it has that flag the GC knowns to remove it from the interned string table. The keyword to know to search for this in the VM is `fstring`, that's what interned strings are called internally: -…
Ah, the value of FL_FSTR was what I was missing, I had followed this code into rb_gc_free_fstring without realizing what FL_FSTR meant. Thank you!
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#99The 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 l…
That'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.
Yeah 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.
Re: Ruby 3.4 frozen string literals: What Rails developers need to know
#100Earlier quoted context omitted.
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?
You can, but allocating and deallocating is more tedious without a GC, and if you care about performance, you might want to have mutable strings.