←back to thread

Flattening Rust’s learning curve

(corrode.dev)
452 points birdculture | 6 comments | 13 May 25 22:25 UTC | HN request time: 1.146s | source | bottom
Show context
baalimago ◴[14 May 25 05:32 UTC] No.43981145[source]▶
>For instance, why do you have to call to_string() on a thing that’s already a string?

It's so hard for me to take Rust seriously when I have to find out answers to unintuitive question like this

replies(7): >>43981274 #>>43981417 #>>43981621 #>>43981663 #>>43981709 #>>43981713 #>>43982610 #
umanwizard ◴[14 May 25 07:08 UTC] No.43981709[source]▶
I’m not sure why it’s counterintuitive that &str and String are different things. Do you also find it counterintuitive in C++ that std::string is different from const char* ? What about &[u8] and Vec<u8> ?
replies(1): >>43982037 #
1. dezgeg ◴[14 May 25 07:54 UTC] No.43982037[source]▶
Better analogy is std::string_view vs std::string
replies(2): >>43982531 #>>43986461 #
2. scotty79 ◴[14 May 25 09:20 UTC] No.43982531[source]▶
Nah. &str is const char* exactly. It's as primitive as types in rust get.
replies(1): >>43983275 #
3. tuetuopay ◴[14 May 25 11:39 UTC] No.43983275[source]▶
Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.
replies(1): >>43987860 #
4. umanwizard ◴[14 May 25 16:30 UTC] No.43986461[source]▶
Technically that's a bit closer, yes, but way more people have heard of char* than string_view, and char* is similar _enough_ to &str that the analogy still works.
5. umanwizard ◴[14 May 25 18:41 UTC] No.43987860{3}[source]▶
Another difference is that &str is guaranteed to be utf-8, whereas const char* can be any encoding (or no encoding).
replies(1): >>43989775 #
6. pdpi ◴[14 May 25 22:19 UTC] No.43989775{4}[source]▶
Also, &str is closer to const uint8_t* than it is to const char*. Chars are signed by default and are at least 8 bits, but can be wider.