>For instance, why do you have to call to_string() on a thing that’s already a s...

akewovtsn · 2025-05-14T07:09:23 1747206563

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 · 2025-05-16T09:15:54 1747386954

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 · 2025-05-14T09:35:07 1747215307

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 · 2025-05-16T09:18:35 1747387115

  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 · 2025-05-19T07:14:21 1747638861

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.

umanwizard · 2025-05-14T07:08:36 1747206516

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 · 2025-05-14T07:54:58 1747209298

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

umanwizard · 2025-05-14T16:30:42 1747240242

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 · 2025-05-14T09:20:54 1747214454

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

tuetuopay · 2025-05-14T11:39:11 1747222751

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

umanwizard · 2025-05-14T18:41:37 1747248097

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

pdpi · 2025-05-14T22:19:43 1747261183

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.

joatmon-snoo · 2025-05-14T06:54:27 1747205667

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 · 2025-05-14T07:00:13 1747206013

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.

SkiFire13 · 2025-05-14T06:16:54 1747203414

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 · 2025-05-14T10:02:06 1747216926

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 · 2025-05-16T09:17:51 1747387071

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 · 2025-05-16T12:48:13 1747399693

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)

3836293648 · 2025-05-14T05:56:49 1747202209

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.