I just want to ask any experienced C++ user who has learn't C++ first. After learning C++ when you started to learn Rust, was it easy to port over to Rust in terms of learning it? How similar is Rust compared to C++?
They are similar as they both are systems programming languages without garbage collector. For me learning Rust wasn't difficult since many concepts are same in C++.
Syntax of Rust is modern and I found it easier and fun to work with.
Biggest challenge was the borrow checker, it needs practice and would take sometime to understand why it is giving errors. But borrow checker is blessing in a disguise as it will not let bad code compile, at least memory safety wise.
5 Likes
To be frank, after a while (~1yr for me) of writing code in rust, I've found that I now structure my code more efficiently (As in more like what the borrow checker expects), and barely ever have to deal with the borrow checker. Intuition is built pretty fast if you put the effort into practicing it and learning how to appeal to the borrow checker.
I personally don't really interact with C++ though, so that might be different.
2 Likes
But what about the learning curve though? Are they both similar to learn?
Yes true of course.
The steepness of the C++ learning curve is off the scale. It is such a huge and complex language that I do not believe that a single human being understands all it parts and how they interact with each other. It also contains a million undefined behaviors that one has to be aware of.
As far as I can tell Rust is also a huge language. As a long time C/C++ user I have only scraped the surface of Rust (see what I did there 
) in the few months I have been investigating it. I know nothing of Rust macros for example.
A couple of points:
-
Do not expect to be reproducing weird and complex class hierarchies with multiple inheritance C++ style in Rust. A practice which is increasingly frowned upon in the C++ community anyway.
-
The borrow checker and it's notion of ownership and aliasing seems to cause grief for some. Certainly the compiler nags you a lot about it. BUT the reality is you have to learn to code like that in C++ as well, else your programs will fail in mysterious ways. It's far easier to learn that from compiler errors than having to learn it from long hours of tracking down and debugging mysterious failures in your products.
-
Arguably it is easier to learn Rust from the (usually) excellent error messages and suggestions of the compiler. I have found that it's an educational experience to actually role up your sleeves, start coding, and have a conversation with the compiler. Far more so than ever was in C++.
-
If you are into generics and template meta programming I cannot advise. I have never been good at that in C++ and not looked into creating macros in Rust yet.
-
Basically if you have the wits to become somewhat proficient in C++ then Rust should not be a problem to learn. You will find yourself wondering "Why doesn't C++ do it like that" more and more as you go along!
12 Likes
Is this your personal experience?
What ZiCog said.
Short answer, I found Rust easier. And, imo, both are similar to learn. Having programmed in C/C#/Go/Ada/C++/Rust, I find C++ and Rust very close to each other.
3 Likes
Yes.
Hmm... some background: I learned to program decades ago in BASIC at age 15. At university I used ALGOL. When my studies (physics) were over I took a job at a technology company hoping to get into electronics. I found myself spending more and more of my time programming embedded real-time systems in assembler. A few years later I went freelance and was involved in a string of projects at various companies that involved significant use of use of PL/M, Coral, Lucol, Ada and latterly C and C++.
I was coming to the conclusion that programming languages are generally more alike than different. It was making me crazy having to learn a new syntax and semantics and all the libraries and tooling over and over for each new project.
Frankly I was disillusioned and bored with it all. It all seemed like a pointless waste of time.
Until I had to use Javascript and node.js a few years back. Finally a language with actual new features in it's semantics: Lambda functions, closures the whole event driven model.Wonderful! An eye opener and a breath of fresh air for me. (Not new for those that had been exposed to languages like Lisp, Scheme, and functional programming etc. But new to me in my world of embedded real-time systems and such like)
Now comes Rust. Amazing, the only other language I have come across that offers genuinely new and very useful features. In particular that whole notion of the borrow checker and preventing dangerous aliasing. Also in particular the absence of all those undefined behaviors that plague C/C++ and other languages. Also in particular the insistence on actually being useful in my world as a systems programming language with little overheads and no run time.
So yes, learning Rust may not be trivial but for sure if you are competent at C++ then Rust should not be a huge challenge.
A major concern when learning and using a new language is getting to grips with the huge array of libraries one is likely to want to use. The whole ecosystem of the thing. I have found that for the most part that is a much easier proposition in Rust with it's crate system. There is already a lot of crates available and for the most part they are far easier to find and use than one would ever dream of in the C++ world!
7 Likes
I've written this before but since OP explicitly asked here: I've been using C++ as my primary language before switching over to Rust. Rust had practically no learning curve for me, as the ownership/borrowing rules the compiler enforces are basically "only" formal codifications of the idioms that practicioners of modern C++ are encouraged to use anyway.
7 Likes
I think this varies from person to person. Yeah, it does seem that "fighting the borrow checker" is a phase you have to go through to become proficient, but just from lurking in threads like this one, people spend varying amounts of time and effort getting out of that phase. Some people feel it's like learning to program all over again, while others agree with @H2CO3 that the borrow checker only codifies the rules they have already learned.
It may have to do with how you design your C++ programs. C++ is so big that almost nobody uses the same subset as anyone else, so you have "C with classes" programmers and "template all the things" programmers and "lambda all the things" programmers and probably a hundred other breeds. It's only logical that different programmers would develop different habits and intuition for memory safety issues, and maybe some of these are better at teaching the "borrow checker rules" than others.
For what it's worth, I knew C but not C++ when I learned Rust, and I only spent a couple days in confusion before it "clicked". Perhaps oddly, learning Rust gave me confidence to approach C++ and now I use both C and C++ at work, and I wish they both had borrow checkers 
9 Likes
Quite so.
In my experience C++ programmers do not learn those anti-aliasing and ownership idioms when they learn C++. Rather they lean it after some years of spending a lot of time in frustration wondering why their programs produce weird results, random failures and crashes. Eventually they figure out a lot of things NOT to do.
However that is not formal, rigorous or complete. Unless they are lucky enough to be working with old hands at C++ who do that encouraging you mentioned and beat them over the head with the standard and whatever house coding standards they have at review time.
It's a slow and unreliable process. A very long shallow learning curve if you like.
When you start with Rust those idioms are enforced and so there is a lot more to think about up front before you get a program that compiles and runs. Which is why some may perceive the learning curve to be steeper.
Edit: Actually from watching a lot of CppCon presentations in recent years I get the impression that there is a lot more discussion of the issues of aliasing and ownership in C++ in the air now a days. At least among the elites of C++ that attend such events.
7 Likes
It's not necessarily the elites, although I agree that you need to care about correctness, style, and stuff like that in order to be involved in such discussions. A couple of years ago I was an active participant on Stack Overflow for over 3 years and people definitely did give and get a lot of this advice. Unfortunately, it wasn't really very clear, or rather, the one simple RWLock pattern behind the problem wasn't very clear in their advice. Instead, there were many, seemingly disconnected pieces of advice as to how we avoid memory corruption in specific cases. These were all rules of thumb and one-off techniques, without a deeper understanding of why we need them.
The C++ committee even seems to want to catch up to features like the ownership model or traits/typeclasses for generics using "Concepts" nowadays; although as usual, the result is a huge, purely additive change to the language, with even more special syntax, even more cruft, and – countering the purpose and the advantages – even more corner cases to learn. If I might go off on a rant, I genuinely do not think that C++ is salvageable at this point, and instead of adding everything that other languages have (even if those are good features), they should simply stop adding stuff already. It would be better for everyone.
5 Likes
Yes, that is what I was getting at above.
Exactly. It's hopeless.
I started to have that feeling some years ago. Since then C++ seems to been spiraling out of control faster and faster. Bjarne Stroustrup himself has likened C++ today to the good ship Vasa which sank yards out into it's maiden voyage: Vasa (ship) - Wikipedia thanks to feature creep.
I really hope this same fate of complexity creep does not happen to Rust. But I have my worries that it is inevitable. More users bring more ideas, more demands for "just this extra little feature to help me with my little problem"
Already I find there is a group dedicated to "parity with C" for Rust. Good grief what? That is like saying C should have parity with assembler. Which it does not have to this day.
(You have to admire and praise the C standards folks for keeping their charge unsullied for so long).
When Microsoft moves in they will no doubt have some baggage to add for their own purposes as well.
Please, let this not happen to Rust!
7 Likes
I've been using more C than C++. To me learning Rust was quite hard, because I had to unlearn many habits from C first.
Rust is made to look like a C-family language, but it isn't. Thinking in C and writing in Rust doesn't work. You need to think in Rust to write in Rust.
Of course, in the end it was worth it. It's a much nicer, more modern and productive language.
5 Likes
To add:
Macros are diabolical in C++ but really very cool in Rust. I have only started out learning macros in rust, but they are very useful and integrated into the language. Rather than the text substitution in C++ that is so difficult.
3 Likes
Not mentioned yet. My biggest difficulty moving from C++ (which I have not used for over a decade, but was once very proficient in a sub set of) has been the lifetime annotation. I think I have finally worked it out, I have a programme on my desk now using life time annotations that is almost compiling...
I have found that one of the most frequent pieces of advice here is "do not use it" but that is wrong. It is worth working out.
Another difficulty is that both C and C++ have brilliant books by the language designers. The writing is superb. In rust there is the book, it is good, but it is not brilliant. The documentation for rust is extensive, it is high quality, but I have not found a resource like those C and C++ books.
That is a very subjective opinion, and given the choice I would rather have a brilliant language with adequate documentation (Rust) rather than a adequate language with a brilliant book (C or C++)
3 Likes
Just curious, what C or C++ books do you think are brilliant in a way that Rust documentation isn't? I generally disagree with that sentiment as:
- The K&R book for C is severely outdated, although it at least doesn't give bad advice because the language has been so stable for decades. It could just use an update with a more modern and structured/principled approach to writing code.
- There's not really any other authoritative book on C.
- C++ books are a lot easier to come around, but apart from Stroustrup's and Scott Meyers' ones, the quality is generally pretty low, this time full of bad advice.
- Furthermore, I don't find either K&R, Stroustrups "The C++ Programming Language" nor Meyers' "{More,} Effective {Modern,} C++" more "brilliant" than the Rust book or "Rust by example". This is not to say that they are worse or that they are not great. They are great, but the Rust book is also full of clear, intuitive explanations, copy-pasteable examples ready to run, structured in a step-by-step, cumulative, didactic manner.
3 Likes
Stroustrups "The C++ Programming Language" and Meyers "Effective Modern C++ Programming" are very comprehensive.
2 Likes
To add to the discussion:
Even if programmers are using those, in a large/complex project it is easy to make mistakes even by very good and experienced programmers following correct memory safety standards and practices; hence, imo, it is much better for the compiler to enforce these rules. There are some switches in C/C++ that helps a little but nothing to the level of the Rust compiler.
I agree.