←back to thread

Flattening Rust’s learning curve

(corrode.dev)
452 points birdculture | 4 comments | 13 May 25 22:25 UTC | HN request time: 0.818s | source
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 #
1. 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 #
2. 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 #
3. int_19h ◴[16 May 25 09:17 UTC] No.44003312[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 #
4. swiftcoder ◴[16 May 25 12:48 UTC] No.44004824{3}[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)