Hacker News Reader

Comment by baalimago | Hacker News Reader

>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

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.

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.

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.

  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

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.

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

Better analogy is std::string_view vs std::string

Nah. &str is const char* exactly. It's as primitive as types in rust get.

Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.

Another difference is that &str is guaranteed to be utf-8, whereas const char* can be any encoding (or no encoding).

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.

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.

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.

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.

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.

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

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).

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)

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.

Reply on news.ycombinator.com