For example, when iterating over text, you can’t tell it to just give you a view/pointer into the existing memory of the text. Instead, it copies each snippet of text you want to process into new memory.
As someone used to embedded programming, this sounds horrific.
Yep. I used to code a lot in JVM languages, then started learning Rust. My initial reaction was “Why the hell does Rust have two string types?”.
Then I learned that it’s for representing actual memory vs. view and what that meant. Since then I’m thinking “Why the hell do JVM languages not have two string types?”.
I’m not a java programmer, but I think the equivalent to str would be char[]. However the ergonomics of rust for str isn’t there for char[], so java devs probably use String everywhere.
Nope, crucial difference between Java’s char[] and Rust’s &str is that the latter is always a pointer to an existing section of memory. When you create a char[], it allocates a new section of memory (and then you get a pointer to that).
One thing that they might be able to do, is to optimize it in the JVM, akin to Rust’s Cow.
Basically, you could share the same section of memory between multiple String instances and only if someone writes to their instance of that String, then you copy it into new memory and do the modification there.
Java doesn’t have mutability semantics, which Rust uses for this, but I guess, with object encapsulation, they could manually implement it whenever a potentially modifying method is called…?
As someone used to embedded programming, this sounds horrific.
Yep. I used to code a lot in JVM languages, then started learning Rust. My initial reaction was “Why the hell does Rust have two string types?”.
Then I learned that it’s for representing actual memory vs. view and what that meant. Since then I’m thinking “Why the hell do JVM languages not have two string types?”.
I’m not a java programmer, but I think the equivalent to str would be char[]. However the ergonomics of rust for str isn’t there for char[], so java devs probably use String everywhere.
Nope, crucial difference between Java’s
char[]and Rust’s&stris that the latter is always a pointer to an existing section of memory. When you create achar[], it allocates a new section of memory (and then you get a pointer to that).One thing that they might be able to do, is to optimize it in the JVM, akin to Rust’s
Cow.Basically, you could share the same section of memory between multiple
Stringinstances and only if someone writes to their instance of thatString, then you copy it into new memory and do the modification there.Java doesn’t have mutability semantics, which Rust uses for this, but I guess, with object encapsulation, they could manually implement it whenever a potentially modifying method is called…?