Objective opinion about Rust safety/speed

In Rust you'd typically use iterators much more often then in C++. For example

let s = "Hello";

let s2 = s.chars().take(s.len() / 2).collect::<String>();

println!("{}", s2);

Playground link

I find iterators more readable and easier to use than what I usually end up using in C++. Especially since lambdas in Rust are a lot less verbose.

1 Like

That's just my personal opinion — you can deem it as right or wrong. Whether or not it is an exact replacement isn't very important, I would say.

As I said before, borrow checking (and the concept of lifetimes in general) is very attractive to me, for example — it hindered me at the beginning, but it really saves me hours of headache with GDB and core dumps and stuff. Like writing C++ code like this: (contrived example)

std::string_view suffix = vec[0];
for (auto& s : vec) {
    s += suffix;
}

and wondering how I got the amusing result.

Rust doesn't have to exactly replace C++ to have significance — the way people think of programming evolves and refines, and new concepts are certainly valuable in improving the correctness of code.

What @2e71828 said. (And you don't get portability bugs caused by using int to iterate over the string rather than std::size_t — even in C++ I like iterators and ranges)

Yes, that's why I'm investing in Rust. But the execution of how code/programs in Rust are being written is in my opinion ugly. Yes, it is very subjective.

By the way, in addition to what @qaopm said, you can also avoid the allocation if you are working with bytes:

let s = "Hello";

let s2 = &s[0..s.len() / 2]; // a &str pointing to the "He" part

println!("{}", s2);
1 Like

But your personal opinion is contradicting the pillars of Rust.

Take a look at other people's opinion on this:

Thanks, that looks really good.

1 Like

This example may look like it works, but this pattern is buggy in that it assumes that whatever is in s contains only ASCII. This assumption is true for the example verbatim, but if there are any non-ASCII unicode graphemes in the string, indexing a string can easily break, meaning you end up with broken parts of graphemes e.g. an é without the base e (leaving only the accent) or vice versa.

2 Likes

To be fair, the original C++ code is also broken with multibyte characters.

Looks like it'll panic, e.g.:

 let s = "\u{2602}";

results in

thread 'main' panicked at 'byte index 1 is not a char boundary; it is inside '☂' (bytes 0..3) of `☂`',  ...

Multibyte is very rare in C++

This is yet another example of broken promise by Rust. Rust is not safe by default. It allows you write code that it will crash your software. Full stop.

The fact that it fails predictably is great, but also kind of irrelevant in this context, because the code is buggy regardless of whether and how it communicates the failure to the user.
The recommended way to handle this would be to use the unicode_segmentation crate.

Rust never promised that it would allow you to write code that can't crash. This is, in general, not a promise that can be fulfilled. At all.

2 Likes

What do you mean fails predictably? During runtime you will not be able to predict the precise character that is being assigned to the variable.
It is like saying that in C++ it is predictable that if you access nullptr you'll get crash

Rust promised no memory corruption

I don't know how objective I manage to be, I can speak only from my own experience. But I'll try.

Not every language is fit for every purpose and not every language is fit for every person. So if you like or don't like the syntax, that's personal but valid. Part of that is probably what you're used to, part might be just your mental model. I personally find rust syntax quite nice and don't like the C++ syntax. Sure, I could find places where it could be improved or how I would like it better. But I've also coded extensibly in Perl and found its syntax nice in its own way and I know the opinions of many people on that won't agree with me.

As for the claim that one can code faster in whatever other language. That also depends a lot on the person and the task at hand. I can believe someone codes faster in Go or Python. Some things I code in shell and that can be fast coding. But when I consider something bigger, I myself work faster with Rust than in the other languages because I can lean onto its strong type system and can pull in libraries easily. Using the strong type system to speed up development is something that takes some learning.

Apart from „it depends“, I can definitely say that I see a reason for Rust to exist. Some things just can't be written in Python or in Go because of performance characteristics, memory consumption or other reasons. For these there's basically the option of C, C++ and Rust. And of these, Rust is the fastest to develop in for me (and for many people I know) and also won't regularly stab you in the back with some kind of combo about inheritance & template resolution leading to UB nobody really saw coming. I don't know if you end up being 2% faster or slower than if you coded the same thing in C++, but Rusts definitely is playing on the same field as the other two when it comes to performance. Sometimes you can get good speed ups because you dare to do things that would feel too dangerous in C++, because the compiler checks them for you. But otherwise, equivalent code will likely produce equivalent performance.

Now I have code in production that runs fast, doesn't crash and replaced older system in Java that was not able to handle what was needed of it. I'm quite confident writing it in C++ would produce more bugs on the way and would take much longer.

So, overall, Rust isn't exactly easy to learn, but depending on if you invest in it and what you want to do about it, it might be worth it.

And, just a point in the „didn't wow me“, I've started learning it because I thought the marketing claims about the safety and such must be fake and wanted to prove them wrong.

2 Likes

Rust promises no memory corruption for safe code. With unsafe code you as the developer bear much more responsibility for the correctness of the code, much as in C.

As for the string indexing example, no memory was corrupted there. The panic (which is the predictable failure I was talking about, contrast this with eg silent failure where you don't even know it's happening) prevented that.

1 Like

And did you? Because I did.

Is this a serious statement, lack of experience or an attempt to troll? Every project I've been working on in the last 25 projects used multibyte/UTF-8 strings in C++. The fact that Rust ensures valid utf-8 is a big bonus for my uses cases.

1 Like

The official ones, no. I've learned they are a bit nuanced.

There's a lot of unofficial false claims (like Rust preventing memory leaks) which circulate the internet, but I meant the safety ones.