Hacker News Reader

Comment by sbjs | Hacker News Reader

I want to expand my knowledge but don't know whether to invest in learning C++ or Rust. Both look like they have interesting concepts, but Rust is new and not yet widely used, and I hear C++ is easy to break in confusing ways. (I have cut Go out of the picture because copying and pasting code is the first thing you learn not to do in school, but all the Go leaders say you have to do this since they don't want to implement generics, so I don't trust their judgment on language design.)

View on HN

I'm not an expert in either language, so take this with a grain of salt, but I've been using Rust pretty regularly for a range of hobby projects since just before Rust 1.0 released, and recently spent the last few months messing around with C++ trying GUI development with Qt. I thought that Rust was much easier to get a grasp of than C++, the main differences being documentation and Rust felt like it had a more consistent design. By consistent design, I mean that C++ constantly felt like a mix of C along with some newer features tacked on, but Rust just felt like Rust, and there wasn't any syntax that felt out of place. I think the documentation issues I had are mainly because of the age of C++, it kind of reminded me javascript where you can ask the same question and get 5 different, but valid, answers. Overall, Rust required a lot of learning up front, but the official documentation is excellent. C++ felt like following a trail of breadcrumbs where each resource gave me a piece of the answer I was looking for, increasing the amount of time it took to figure something out.

You might need to re-think Go. The people who designed it know far more about language design that the people who taught you in school. And they still made choices that the people teaching you in school think are wrong. Instead of thinking "How could they be so stupid?", you should think "Hmm... I wonder why? What do the Go designers see that those other people don't?"

The lack of generics in Go is a sore spot. It's quite possible to solve. The Go designers are not solving it, because they want other things more than they want generics, and they aren't willing to give up those other things in order to get generics.

For any given project, that could still be the wrong choice. For that project, then, reject Go. But don't totally reject the language because you don't trust the Go leaders' judgment on language design. It is more reasonable to mistrust your own.

If you're trying to expand your knowledge, then waffling over which thing to learn is just procrastination.

Well... to learn a language moderately well takes weeks. To learn it really well takes months. To learn it at an expert level takes years. It might be worth a day or two of thought before that kind of investment. Eventually, sure, it becomes procrastination. But just randomly choosing isn't really the optimal approach either.

No. By that logic, you could as well open a random page on Wikipedia and start learning new stuff. Choosing to study a certain technology in depth carries with it a high opportunity cost in the form of your time.

They are almost equivalent choices in terms of return of investment. C++ is used almost everywhere. Rust will allow you to write programs with less bugs and similar performance to C++.

The opportunity cost of figuring out which one is better can often be higher than just trying out both choices. [1]

[1] https://xkcd.com/1445/

> They are almost equivalent choices in terms of return of investment.

Someone who asks whether they should learn C++ or Rust probably doesn't know this – otherwise, they wouldn't ask.

I will tell you what works for me. Dont try to make one language to fit all cases, but try to use the best tech for each scenario.

In the past you had to learn a lot of languages and platforms and you still need it in some cases. But for my particular needs, i've managed to narrow down mostly to 2 languages: C++ and Swift. But thats for me, for others it will be different things.

But dont try to find the perfect language.. dont be a hostage to any tech suffering with stockholm syndrome with a given piece of tech.

This weird trend of one tech-fits-all started back in the nineties with Java, with things comming out straight from the religions like 'evangelism', and calling people infidels for trying different things.

Maybe whats work for me will work for you too. I bet you can narrow down to 2 langs to do almost anything you want.

About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams.

But of course, if i were to create a program to control a nuclear reactor or a submarine i would consider using Rust or Ada. But particularly i find Rust programming more stressful than C++ without (almost) nothing to gain. And on the language design aspect where Rust is superior to C++, i prefer to use Swift if i can, which i consider 'a better Rust'.

By the way in a lot of cases you might consider using Rust or C++, you can use the joyful Swift. Using a powerful language with less of a burden.

TLDR; Where some people will try to use Rust for everything, i prefer to use a Swift/C++ combo, and given you can mix both without much problem in a single program, i hardly need or miss anything else.

I don't think any embedded systems engineers are programming in Rust for nuclear reactors or subs, and I don't think they are considering it either. No amount of safety constraints in Rust make up for the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean. Not to mention those are usually legacy codebases from before Rust even existed, and no one is convincing the DoD or the DoE to "rewrite in Rust".

> the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean

What cases are you thinking of here?

Well I suppose backwards compat might have been the wrong phrase here. I'm thinking more that it's a language whose v1.0 release was only 3 years ago before which it was "difficult to maintain projects written in Rust, since the language and standard library were constantly changing" [0]. That's not to say that it isn't a stable language now (and I actually quite like it) but with only 3 years of stability to show, "nuclear reactors" and "submarines" are strange things to list as applications for the language.

[0] (https://blog.rust-lang.org/2015/05/15/Rust-1.0.html)

> About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams.

Is there a book (or other type of resource) that approaches C++ from the "modern" direction, i.e. with a focus on correctness?

" but all the Go leaders say you have to do this since they don't want to implement generics" they never said that.

Why not both?

https://github.com/nrc/r4cppp

https://www.reddit.com/r/rust/comments/71w6ht/is_there_a_c_f...

C++ sucks big time when it comes to "management" - there's no official compiler, no official package manager, no package registry, no easy dependency handling. It's easy to start with sane C++ and then "oh, I need a library for X", and you just wandered into a forsaken of hell accidentally. [ https://i.imgur.com/a4CVG.jpg ]

A strategy that has worked well for me was to only use Qt and libraries based on Qt with C++. Qt is pretty comprehensive for a lot of usecases, and has a rich ecosystem of third-party libraries that follow the same conventions as the Qt APIs.

They have pretty solid reasons on why they are delaying the support for generics actually.

Check this out https://www.youtube.com/watch?v=sX8r6zATHGU

Reply on news.ycombinator.com