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

101–110 of 131 posts

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

#101

Post by shikon7 »

steveklabnik wrote: post #84
fud101 wrote: post #27

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

There is also &mut str. The nice thing about Rust is that the same memory area can be used as a "StringBuilder" with &mut str, and then as a "String" with &str. Once you have a &str reference, Rust statically guarantees that no one else cam mutate it.

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

#102

Post by steveklabnik »

shikon7 wrote: post #101
steveklabnik wrote: post #84

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

There is also &mut str. The nice thing about Rust is that the same memory area can be used as a "StringBuilder" with &mut str, and then as a "String" with &str. Once you have a &str reference, Rust statically guarantees that no one else cam mutate it.

Yeah the type is really just str but I didn’t want to get into it. &mut str is kinda weird.

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

#103

Post by runeblaze »

corytheboyd wrote: post #44
jashmatthews wrote: post #39

Earlier quoted context omitted.

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

Well thats great, guess I have carried that baggage with me as misinformation for years now.

Same here. Turns out writing too much code for RPG Maker XP when young ruins one’s perception of Ruby forever

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

#104

Post by phendrenad2 »

byroot wrote: post #78
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

Ah excellent. Seems like a modest performance improvement.

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

#105

Post by echelon »

fud101 wrote: post #27
masklinn wrote: post #23

Earlier quoted context omitted.

Also JavaScript.

Java too. Rust has only 99 string types, some of those are immutable also.

Rust has one core String type.

  String

  &str

  &mut str

  &'static str 

  etc.
These are just the language semantics.

The other string types are non-Rust strings. Filesystem, C strings, etc. You only deal with them in dealing with specific OS and binding interfaces.

95% of the time you'll just be using String.

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

#106

Post by typeofhuman »

corytheboyd wrote: post #48
zht wrote: post #45

Earlier quoted context omitted.

dynamically created symbols have been garbage collected for almost 10 years

Yeah I am a moron. Updated.

No. A moron would refuse to learn. You are open minded and humble.

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

#107

Post by throwawaymaths »

ttoinou wrote: post #92
throwawaymaths wrote: post #63

Earlier quoted context omitted.

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

still better than ruby in efficiency department

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

#108

Post by drewcoo »

taeric wrote: post #70
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…

It 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

It's not a party unless someone talks about Lisp. Or maybe Rust.

Oh, I think I see some nameless person I know over there. Well-met Lisper, but goodbye!

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

#109

Post by masklinn »

ameliaquining wrote: post #95
fud101 wrote: post #27

Earlier quoted context omitted.

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

By your incredible criteria of things being mutable strings if they behave nothing like strings but can produce one, JavaScript absolutely does have a mutable string, it’s called Array. It’s also a mutable integer.

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

#110

Post by johncolanduoni »

vnorilo wrote: post #37
IshKebab wrote: post #26

Earlier quoted context omitted.

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

It’s worth noting that C++ standard libraries have mostly moved away from copy-on-write strings, due to their poor performance in multithreaded scenarios. And JavaScript engines have ended up adding a bunch of optimizations that simulate mutable strings in certain common scenarios. It depends on what the code in question is doing, and I think the ideal scenario is to allow both in different contexts as long as they can be kept distinct.
Post reply on HN