Most active commenters
  • umanwizard(3)
  • int_19h(3)

←back to thread

Flattening Rust’s learning curve

(corrode.dev)
451 points birdculture | 19 comments | 13 May 25 22:25 UTC | HN request time: 0.938s | source | bottom
1. 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 #
2. 3836293648 ◴[14 May 25 05:56 UTC] No.43981274[source]▶
C++ is a horribly cmplicated language, sometimes I have to cast something to an int when it's already an integer. /s

I have a hard time understanding why people have such a hard time accepting that you need to convert between different text representations when it's perfectly accepted for numbers.

3. SkiFire13 ◴[14 May 25 06:16 UTC] No.43981417[source]▶
Just because a language is not high level enough to have a unique concept of "string" type doesn't mean you shouldn't take it seriously.
replies(1): >>43982729 #
4. joatmon-snoo ◴[14 May 25 06:54 UTC] No.43981621[source]▶
Strings are like time objects: most people and languages only ever deal with simplified versions of them that skip a lot of edge cases around how they work.

Unfortunately going from most languages to Rust forces you to speedrun this transition.

5. winrid ◴[14 May 25 07:00 UTC] No.43981663[source]▶
The question is worded weird for fun. One is a string slice (like char*) and one is String or &String, which is closer to an object.
6. 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 #
7. akewovtsn ◴[14 May 25 07:09 UTC] No.43981713[source]▶
Python community famously learned the hard way that sometimes the programmer needs to know that there are multiple kinds of string.

Personally, I’ve been using to_owned instead. Some of the people looking at my code don’t write rust, and I figure it makes things a bit easier to understand.

replies(1): >>44003304 #
8. dezgeg ◴[14 May 25 07:54 UTC] No.43982037[source]▶
Better analogy is std::string_view vs std::string
replies(2): >>43982531 #>>43986461 #
9. scotty79 ◴[14 May 25 09:20 UTC] No.43982531{3}[source]▶
Nah. &str is const char* exactly. It's as primitive as types in rust get.
replies(1): >>43983275 #
10. darthrupert ◴[14 May 25 09:35 UTC] No.43982610[source]▶
On the other side where this question is not asked we have things like

    > "1" + 2 
    3
And it's utter madness that everyone does anything important with languages like that.
replies(1): >>44003318 #
11. swiftcoder ◴[14 May 25 10:02 UTC] No.43982729[source]▶
Even very high-level languages don't have singular concepts of string. Every serious language I can think of differentiates between:

- A sequence of arbitrary bytes

- A sequence of non-null bytes interpreted as ASCII

- A sequence of unicode code points, in multiple possible encodings

replies(1): >>44003312 #
12. tuetuopay ◴[14 May 25 11:39 UTC] No.43983275{4}[source]▶
Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.
replies(1): >>43987860 #
13. umanwizard ◴[14 May 25 16:30 UTC] No.43986461{3}[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.
14. umanwizard ◴[14 May 25 18:41 UTC] No.43987860{5}[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 #
15. pdpi ◴[14 May 25 22:19 UTC] No.43989775{6}[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.
16. int_19h ◴[16 May 25 09:15 UTC] No.44003304[source]▶
Modern Python has a single type of string.

What used to be called "string" in Python 2 is no longer called that, precisely so as to avoid unnecessary confusion. It's called "bytes", which is why the question of "why do I have to convert it to string?" doesn't arise.

17. int_19h ◴[16 May 25 09:17 UTC] No.44003312{3}[source]▶
I can't think of many languages that differentiate between #1 and #2 in your list. And languages that differentiate between #1 and #3 generally don't refer to #1 as "strings" at all, so you still have a single definitive notion of what a string is (and some other things that are emphatically not strings).
replies(1): >>44004824 #
18. int_19h ◴[16 May 25 09:18 UTC] No.44003318[source]▶

  Python 3.11.12 (main, Apr  8 2025, 14:15:29) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> "1" + 2
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: can only concatenate str (not "int") to str
19. swiftcoder ◴[16 May 25 12:48 UTC] No.44004824{4}[source]▶
Yeah, a bunch of languages don't strongly differentiate between all three of these.

For example, C++ differentiates between #1 and #2 (although it has woefully inadequate out-of-box support for #3).

Python (> 3) calls #1 bytes / bytearray, and calls #3 string. #2 is only really supported for FFI with C (i.e. ctypes.c_char_p and friends)