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

111–120 of 131 posts

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

#111

Post by simonask »

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.

You can't really do anything useful with a `&mut str`. For example, you can't change the length of the string or any characters in the string (without unsafe code). The latter is perhaps surprising, but it's because strings in Rust are always UTF-8, so changing a logical character could imply changing the length of the string, and changing a byte could result in invalid UTF-8.

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

#112

Post by simonask »

steveklabnik wrote: post #97
ameliaquining wrote: post #94

Earlier quoted context omitted.

I would add Path and PathBuf to that list.

Paths are not strings, that's the whole point!

Well... They're also not _not_ strings. In fact, what a perfect candidate for introducing a special type. :-)

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

#113

Post by whytevuhuni »

simonask wrote: post #111
shikon7 wrote: post #101

Earlier quoted context omitted.

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.

You can't really do anything useful with a `&mut str`. For example, you can't change the length of the string or any characters in the string (without unsafe code). The latter is perhaps surprising, but it's because strings in Rust are always UTF-8, so changing a logical character could imply changing the length of the string, and changing a byte could result in invalid UTF-8.

You're right, but just to add a bit more to this, you can call make_ascii_lowercase and make_ascii_uppercase on &mut str, which can sometimes be useful.

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

#114

Post by fud101 »

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.

99.9% of the time rust has 1 string type. The other 0.1% of the time it has 99, got it.

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

#115

Post by _flux »

debugnik wrote: post #33
_flux wrote: 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.

Oops, that's not a nitpick but a good correction :).

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

#116

Post by rurban »

fiddlerwoaroof wrote: post #64
OskarS wrote: post #5

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.

Common Lisp and Smalltalk have mutable strings, I think. So it’s not too surprising that ruby does too, since it was pretty heavily influenced by these languages.

Amongst the lisps, AutoLISP had the one standout feature that was immutable strings by default. Many other lisps wished they could have that too, esp. for the GC.

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

#118

Post by steveklabnik »

fud101 wrote: post #114
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.

99.9% of the time rust has 1 string type. The other 0.1% of the time it has 99, got it.

It has two, not 99, with owned and borrowed pairs.

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

#119

Post by ksec »

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

Post reply on HN