5 ms·

>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 answe

>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

3836293648 1y ago
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.
SkiFire13 1y ago
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.
- swiftcoder 1y ago
  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
  - int_19h 1y ago
    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).
    - swiftcoder 1y ago
      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)
joatmon-snoo 1y ago
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.
winrid 1y ago
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.
School-Cotton 1y ago
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> ?
- dezgeg 1y ago
  Better analogy is std::string_view vs std::string
  - School-Cotton 1y ago
    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.
  - scotty79 1y ago
    Nah. &str is const char* exactly. It's as primitive as types in rust get.
    - tuetuopay 1y ago
      Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.
      - School-Cotton 1y ago
        Another difference is that &str is guaranteed to be utf-8, whereas const char* can be any encoding (or no encoding).
        pdpi 1y ago
        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.
akewovtsn 1y ago
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.
- int_19h 1y ago
  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.
darthrupert 1y ago
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.
- int_19h 1y ago
  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
  - darthrupert 1y ago
    Yes, python has strong typing and in that sense passes this bar. It's a fine choice for many things, and if you enforce certain things in CI, it can be a good choice for many more.

>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

3836293648 1y ago

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.

SkiFire13 1y ago

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.

swiftcoder 1y ago
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
- int_19h 1y ago
  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).
  - swiftcoder 1y ago
    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)

joatmon-snoo 1y ago

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.

winrid 1y ago

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.

School-Cotton 1y ago

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> ?

dezgeg 1y ago
Better analogy is std::string_view vs std::string
- School-Cotton 1y ago
  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.
- scotty79 1y ago
  Nah. &str is const char* exactly. It's as primitive as types in rust get.
  - tuetuopay 1y ago
    Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.
    - School-Cotton 1y ago
      Another difference is that &str is guaranteed to be utf-8, whereas const char* can be any encoding (or no encoding).
      - pdpi 1y ago
        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.

akewovtsn 1y ago

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.

int_19h 1y ago
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.

darthrupert 1y ago

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.

int_19h 1y ago
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
- darthrupert 1y ago
  Yes, python has strong typing and in that sense passes this bar. It's a fine choice for many things, and if you enforce certain things in CI, it can be a good choice for many more.