4 ms·

Why is it impossible in Rust? Do you have any source for that?

steveklabnik 2y ago
It is not. It is not implemented in std::string::String, but (as pointed out elsewhere in this thread) there are other string implementations that have it. It was decided explicitly against for the standard library, because not every optimization is universally good, and keeping String as a thin wrapper over Vec<T> is a good default.
- mhh__ 2y ago
  When are small strings bad? Parallelism?
  - workingjubilee 2y ago
    The "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc. You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.
  - n_plus_1_acc 2y ago
    You'll need to branch on most operations to check "am i small?". This may cause issues with the Branche predictor.
  - kibwen 2y ago
    Rust APIs use string slices (&str) extensively. With its current design, converting from a String to a &str is a no-op; if String instead did small string optimization, converting to &str wouldn't be free. Furthermore, thanks to the borrow checker, Rust code tends to avoid copying strings around, so the benefit of SSO is reduced. C++ does more string copying and didn't have a standard string_view for a long time, so considering the tradeoffs both languages made reasonable decisions.
  - steveklabnik 2y ago
    Just wanted to say that I only got back to this thread now, but I agree with my sibling commentors. Here's a discussion about it from a few years back, with some links to the primary discussions: https://news.ycombinator.com/item?id=18372332 https://news.ycombinator.com/item?id=18372332
  - CJefferson 2y ago
    It adds a branch every time you access the string (to check if it is small or not), and can stop various optimisations. g++ used to have small string optimisation, but (eventually) removed it.
- jerf 2y ago
  This is one of those things that I wish people would speak more carefully about. I've seen it in every programming language community I've participated in, so it's not a language-specific thing, but... one should not say "language X does not do a thing" when they mean "language X's standard library does not do a thing". That the "language" doesn't do a thing should be reserved for the cases where the language itself really does preclude some particular thing for some reason. Otherwise the relatively inexperienced programmers end up coming away with some really weird mental models of what programming languages can and can not do, just like here. Of course Rust qua Rust can store strings like this, it's basically built for things like this. Any mental model of Rust that thinks Rust qua Rust can't do this is a weird mental model of Rust.
  - steveklabnik 2y ago
    Yep, especially with a systems language. As you say, they're basically built for "I need to do something specific."

It is not. It is not implemented in std::string::String, but (as pointed out elsewhere in this thread) there are other string implementations that have it. It was decided explicitly against for the standard library, because not every optimization is universally good, and keeping String as a thin wrapper over Vec<T> is a good default.

mhh__ 2y ago
When are small strings bad? Parallelism?
- workingjubilee 2y ago
  The "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc. You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.
- n_plus_1_acc 2y ago
  You'll need to branch on most operations to check "am i small?". This may cause issues with the Branche predictor.
- kibwen 2y ago
  Rust APIs use string slices (&str) extensively. With its current design, converting from a String to a &str is a no-op; if String instead did small string optimization, converting to &str wouldn't be free. Furthermore, thanks to the borrow checker, Rust code tends to avoid copying strings around, so the benefit of SSO is reduced. C++ does more string copying and didn't have a standard string_view for a long time, so considering the tradeoffs both languages made reasonable decisions.
- steveklabnik 2y ago
  Just wanted to say that I only got back to this thread now, but I agree with my sibling commentors. Here's a discussion about it from a few years back, with some links to the primary discussions: https://news.ycombinator.com/item?id=18372332 https://news.ycombinator.com/item?id=18372332
- CJefferson 2y ago
  It adds a branch every time you access the string (to check if it is small or not), and can stop various optimisations. g++ used to have small string optimisation, but (eventually) removed it.
jerf 2y ago
This is one of those things that I wish people would speak more carefully about. I've seen it in every programming language community I've participated in, so it's not a language-specific thing, but... one should not say "language X does not do a thing" when they mean "language X's standard library does not do a thing". That the "language" doesn't do a thing should be reserved for the cases where the language itself really does preclude some particular thing for some reason. Otherwise the relatively inexperienced programmers end up coming away with some really weird mental models of what programming languages can and can not do, just like here. Of course Rust qua Rust can store strings like this, it's basically built for things like this. Any mental model of Rust that thinks Rust qua Rust can't do this is a weird mental model of Rust.
- steveklabnik 2y ago
  Yep, especially with a systems language. As you say, they're basically built for "I need to do something specific."