Live data from Hacker News

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

prateekcodes.dev

31–40 of 131 posts

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

#31

Earlier quoted context omitted.

just dont ask about unicode

Unicode support in Ruby has been great since the beginning.

It'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://graysoftin...

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

#33
post #21

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).

Nitpick: `bytes` is the read-write string, `Buffer` is the StringBuilder-like.

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

#36
post #29

Earlier quoted context omitted.

Unicode support in Ruby has been great since the beginning.

No, it was not great during 1.x times. But it has been fairly good since 2.0

So for at least 12 years then. 2.0 was released in 2013.

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

#37

Earlier quoted context omitted.

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

> They're just not especially performant What? Mutable strings are more performant generally. Sometimes immutability allows you to use high level algorithms that provide better performance, but most code doesn't take advantage of that.

Not in general. Immutable strings can be deduplicated, leading to a different performance tradeoff that is often quite good. This is mentioned in TFA.

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

#38
post #30
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.

In 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

I’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.

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

#39
post #30

Earlier quoted context omitted.

In 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

I’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.

Symbols have been GCed since CRuby 2.2 https://bugs.ruby-lang.org/issues/9634

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

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