All of the String types

Under the hood I think they’re both LiteralString now… but I’d argue it’s the fact they they all have different semantics that matters… they’re a bit more than just syntactic sugar. And no, I agree a list[str] isn’t a string type, but I’d say a bytesarray is while a memoryview could be.

And it ignores Vec<u8> and &[u8], which are really common string representations (the byte string version of String and &str respectively). Rust sadly doesn't offer great string processing affordances for these byte string types, but I have lots of code which uses it. It's a great alternative any time the "every string must be valid UTF-8" constraint is inappropriate (which happens a lot when working with external data).

Ditto, I’ve used Rc<str> more than I’ve used Vec<char>.

And I don’t think it’s nitpicky. Claiming that Rust has only 3 string types, then claiming that Vec<char> is one of them, is odd. Does the stdlib even provide string operations on that out of the box?

I'll go you one better - it quite literally is UTF-32 :)

char is guaranteed to have the same size, alignment, and function call ABI as u32 on all platforms.

https://doc.rust-lang.org/std/primitive.char.html#validity-and-layout

You can also cast char to u32 directly with the as operator, so I believe transmuting Vec<char> to Vec<u32> is safe. It is not safe however to transmute from u32 to char as not all u32s are valid chars. char::from_u32 returns an Option<char> and char::from_u32_unchecked is unsafe.

For Zig:

[]const u8 is an immutable, non-null-terminated, non-growable array of bytes.

This isn't true. It's a slice of bytes: a length + a pointer. This distinction is important as

fn foo(s: []const u8) void { ... }

const slice: []const u8 = try alloc(u8, 1024 * 1024);
foo(slice);

Won't make copy 1MiB of data. Whereas the following might:

fn foo(a: [1024 * 1024]u8) void { ... }
const array: [1024 * 1024]u8 = @splat(42);
foo(array);

Arrays are values in Zig. They can be coerced to slices, but they are distinct, unlike in Go which conflates them causing a lot of headaches for newcomers.

Nice article! I might use this as a reference if I end up using some of the latter languages. One minor comment:

&mut str is a non-growable array of characters in which each charcter can be mutated

str is UTF-8 encoded, so mutating a character might require a reallocation if a character's codepoint size changes. It might be better to say that the individual bytes are available for mutation, provided UTF-8 validity over the length of the slice is retained. You can't, however, just start arbitrarily mutating characters.

If one goes through the methods on str and search for &mut self, one sees that - aside from methods used to index and reinterpret as bytes - pretty much the only useful functionality provided by &mut str is make_ascii_uppercase/make_ascii_lowercase, which work only because ASCII characters always have the same codepoint size, avoiding the need to mess with any codepoint offsets.

C#

The whole C# section seems really confused to me.

string is immutable, non-growable list of bytes. It is not unicode aware.

This is... confusing! string is an alias for the System.String type. It is a sequence of UTF-16 code units, not bytes. (That is, when you index a string you get a UTF-16 code unit back.) "not unicode aware" is so vague as to be meaningless, but System.String is natively UTF-16, and .NET as a whole has generally excellent Unicode support. System.String is neither a list nor an array.

cstring is a null terminated version of a string.

There's no cstring in C#, AFAIK!

char [] and char * are mutable non growable list of chars. chars are 2 bytes making them utf-16 code points.

char[] is a character array, not a List. Arrays in .NET can be expanded. char* would be a pointer to a character, and is not usable in safe C#

Finally we have StringBuilder which is [...] a mutable, growable, non-null-terminated array of bytes

As with System.String, it would be more accurate to describe this as a mutable, growable "list" of UTF-16 code units. Although it is not a List.