Objective opinion about Rust safety/speed

Uncategorized
1

Guys, I would really like you to be objective in your replies. I'm new to the Rust (but not new to the programming) and I really would like to know if what Rust promises that is, no memory corruption, no deadlocks, fast or fastest than C++ is true before I decide to invest considerable amount of my personal time into it.
I mean, Rust didn't wow me at all. If anything I consider it to be actually fugly. I am only learning it because of the promises it makes, but those are only promises. And today, I actually stumbled across this video on youtube and I'm really not sure if I want to invest my time in something as ugly and awkward to use:

Any objective responses are really appreciated.
Thanks

2

When you learn something new, you should generally be prepared to be exposed to unfamiliar concepts. Critical thinking is very important in learning, and people are allowed to have different opinions. If you convince yourself that something is "ugly and awkward" before actually learning it, you are going to have a hard time understanding it, and confirmation bias will cause you to actively strengthen your antipathy towards it.

Try not to make that happen. When I see a brand new language (especially languages with concepts that are very different from what I am used to, e.g. Rust), my instinctive initial reaction is often "what the heck is this" as well — it's normal, but I don't want it to prevent me from learning the language.

No language is fit for every purpose, and it's easy to selectively collect use cases and reach conclusions involving "overall," so there isn't really an "objective" statement here. From my experience of learning and working with Rust, I can assure you that, in general, Rust does reach the promises it makes by preventing memory errors and boosting performance — for instance, with the help of the Rust compiler, I feel very comfortable fiddling with references to avoid unnecessary clones without introducing lifetime errors, something I am not confident to do in less safe languages like C and basically unable to do in some other languages.

If you decide that Rust is not fit for your purposes, that's fine too — there are a lot of fields in which Rust is simply not productive enough (yet). Do remember, though, that Rust has its own advantages and use cases as well, and that you are always free to take another look at it when it happens to come in handy.

6 Likes
3

@L.F
It is not the unfamiliar concepts that I find ugly and awkward. It is about the syntax.
The only unfamiliar concepts to me coming from C++ was the memory ownership, borrowing and lifetimes, which I find to be actually excellent.
Rust syntax is to me ugly and I simply cannot overcome it.

4

@L.F
Also, you're talking about fit for purpose. Rust is suppose to be replacement for C/C++. In my opinion Rust is nowhere near. I of course am highly biased against Rust after the initial few weeks of working with it. But that didn't happen to me when I was learning C++ coming from C. It really felt like I'm working with this new improved language. Rust doesn't feel like something fresh. There is something very awkward about Rust.

5

After watching the introduction, his primary point seems to be that Go offers faster development iteration cycles than Rust does. Having never used Go, I can’t speak to the validity of this claim. There are a few counterpoints to consider:

  • Development speed is largely a function of prior experience with the same or similar languages. Rust is more novel than most, so we should expect a larger productivity hit when an experienced programmer tries to learn Rust than some other language. This isn’t particularly strong evidence about how an experienced Rust programmer’s productivity compares to an experienced Go programmer’s in their language of choice.

  • He doesn’t address the cost of long-term maintenance or learning a pre-existing codebase well enough to make meaningful changes. Where Rust really comes into its own is when the type system prevents you from doing something invalid with objects you’re not totally familiar with— that scenario doesn’t really happen in the prototyping stage because you have the entire design in your head at that point.

1 Like
6

He does. You have to let somebody finish talking to the end before replying.

7

Based on the rambling introduction full of references to things he’s not going to talk about, I’m not willing to invest an hour of my time listening to this video. That’s why I made it clear that I only watched the introduction.

10

Can you give us some examples and maybe compare it with C++ equivalent? Perhaps there are ways of expressing things better than your initial experiments. If we can can help restructure the code in a more Rust-ic way, maybe then Rust syntax would make more sense.

11

I'm not sure what purpose this thread serves. There simply aren't objective ways to talk about "fugly". It's highly subjective.

I'm afraid this thread will produce more heat than light.

7 Likes
12

It was weird to me at the beginning as well. As I learned more and got more familiar with Rust, I gradually got used to the syntax, and discovered its beauty. So don't get discouraged if you feel that the syntax is so alien that you can never get used to it.

Nowadays I actually dislike C++ syntax sometimes :neutral_face: EDIT: But I am aware that there's no real reason behind it, and I am willing to throw away the irrational preference and do my best to get used to C++ again.

Well, it isn't. Rust is a new language, distinct from C and C++. Unlike C++, which started as C with classes and developed into a new language, Rust was designed with novel concepts from the beginning. And I don't think it is supposed to cover all applications of C and C++.

C++ inherits most of C's syntax, so that's probably why. I would say that this is a typical case of first impression — you learned the C family of languages first, so your mindset about programming is largely aligned to the way they depict about programming.

Again, as a Rustacean (still a learner at this point) coming from C++, I can reassure you that I can totally relate with your thinking process at the moment (albeit at a less extreme level). Instinctive rejection is very normal when we are trying to adapt to new environments — trust yourself and the new environment, give it a shot, and chances are you can get over the strong sense of unfamiliarity more easily thank you think.

1 Like
13

That video is already discussed at reddit: https://www.reddit.com/r/rust/comments/hkcbnt/back_to_go_rust_is_slooowwww/

1 Like
14

Thanks for the reply. I appreciate it.
But if Rust according to you is not replacement for C++ (but that again, something new because everywhere I'm reading about Rust, it is suppose to be that exact replacement - system level language, so I actually say that you are wrong here) what is the purpose of it? What gap does it fill? What's the point of it then. I swear, I see no point in Rust at that moment. I probably will continue to learn it but it will be something you learn because it can potentially advance your career. No joy in it at all.

15

Sure, iterating over a half of a string for example, yes I want to iterate over half of the string only:
C++
string str{"Hello"};
for(int i{}; i < str.size() / 2; ++)
{
cout << str[i];
}

How would you do that in rust?

16

Assuming you’re not dealing with any multibyte characters (which is equivalent to your C++ code):

for c in s.chars().take(s.len() / 2) {
    /* ... */
}
2 Likes
17

Thanks

1 Like
18

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
19

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)

20

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.

21

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
22

But your personal opinion is contradicting the pillars of Rust.