Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the state of C++ vs. Rust?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 156 posts

Re: Ask HN: What is the state of C++ vs. Rust?

#71

Post by bluejekyll »

Someone wrote: post #32
bluejekyll wrote: post #8

Earlier quoted context omitted.

Like all legacy code, it will not be replaced. Now if people wanted to bifurcate their codebase they can easily add Rust libraries to existing C++ codebases. In my experience I find Rust to be more productive than C++ and easier to write. Obviously that's a pure opinion.

"they can easily add Rust libraries to existing C++ codebases." Is that truly easy? I would expect all kinds of incompatibilities that would require going through a C layer (object layout, difference in virtual method calling, object ownership, etc). For example, calling a C++ function that takes a pair of iterators from Rust and returns a std::map, passing iterators pointing into a Rust hash table, is that easily do…

Well, it depends on the strategy you use, but yes, you're right that it's hard to share strict/objects. But if the API boundary between the two is kept simple and small, then it's simple.

Take a look at the rust ffi omnibus that I posted in this thread. It's object examples show some decent strategies.

Re: Ask HN: What is the state of C++ vs. Rust?

#72

Post by Yoric »

blub wrote: post #62
MichaelMoser123 wrote: post #45

Earlier quoted context omitted.

> I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me. May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like v…

I tend to think carefully about lifetimes, resource ownership and writing secure code. I am careful with threading, use language idioms to enforce safety and also use tools (such as valgrind, but also static analysis) to check the code. This is not as reliable as Rust's compile-time safety checks, but in practice it works well enough for me. I don't think this is typical for all C++ projects or programmers e.g. I am…

Out of curiosity, do you have (open-source) examples of C++ projects that do it right?

In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-collection-has-somehow-been-mutated-during-traversal, etc? I have reached the point where I feel I can't trust any non-trivial C++ code, so I gladly switched to Rust for all my new non-webdev projects.

But back to the question, I would be really happy to see convincingly safe C++ subsets in action. I certainly hope that this would improve my life as a C++ developer, at least for future projects. As a side question, I wonder how many C++ developers actually produce such code.

Re: Ask HN: What is the state of C++ vs. Rust?

#73

Post by Yoric »

bluejekyll wrote: post #29
seren wrote: post #12

Earlier quoted context omitted.

I do agree with you, and I hope this is the future. However, in big organizations, which are not exactly nimble, this is even hard to say, "Okay we've been developing in C++ for 20 years, now the next part of our infrastructure will be written in Rust". This will be seen as an unwanted risk, associated with a training cost. You will have to demonstrate unequivocally Rust's advantage.

Yes, companies that don't want happy employees make these types of monetary decisions. It's their responsibility to their shareholders to do this. It comes at the expense of long-term support of their software though. There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way.

> There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way.

I tend to agree with you (and I'm a big fan of Rust), but I'm nearly certain I heard people saying exactly that ~20 years ago. I don't remember which was the language that was expected to replace C/C++, perhaps Java or Obj-C or perhaps some variant of ML. So far, it hasn't quite happened.

While C/C++ seem to have become much more niche languages in these ~20 years, I suspect that they won't become legacy language any time soon.

Now, I may be wrong. Maybe some revolutionary Rust-base game engine (VR engine? IoT platform?) will shift the landscape drastically any day now, but that's hard to predict.

Re: Ask HN: What is the state of C++ vs. Rust?

#74

Post by Yoric »

sidlls wrote: post #60
steveklabnik wrote: post #33

Earlier quoted context omitted.

Most of Rust's guarantees are provided at compile time and have no overhead, just to be clear.

Yes most, but not all.

Out of curiosity, have you hit examples in which the runtime cost of Rust's safety was problematic – and couldn't be worked around without losing either safety or clarity?

Re: Ask HN: What is the state of C++ vs. Rust?

#75

Post by vvanders »

blub wrote: post #57
vvanders wrote: post #22

Earlier quoted context omitted.

I don't think you can unequivocally dismiss Rust, we've seen Dropbox and other companies pick it up(just yesterday Facebook announced a Mercurial alternative written in Rust). As with each case, it depends. If you've got a well scoped project that is happy with a C ABI(or just stand alone exec) I think there's a compelling case for Rust. I'd also argue if you're looking for top candidates having Rust in-house could b…

I specifically said industry because projects come and go. Yes, there are dozens of companies doing some project in Rust. That's true for almost any programming language. I am guessing that it's going to be another 5-10 years until I would need to seriously consider learning Rust, assuming it will be able to break into the mainstream. Safety-wise it could make sense for my industry, which seems to be overwhelmed by C…

Industry is great if you want to make safe, slow bets. PG's essay on lisp is a great example of why you may not want to follow industry.

However, the point I was making is there's not a binary switch between C/C++/Rust. There's a great interop/FFI story that allows a targeted/gradual adoption.

Re: Ask HN: What is the state of C++ vs. Rust?

#76

Post by zbuf »

k__ wrote: post #42
seren wrote: post #2

Rust is promising but C++ is here to stay. If you have a legacy C++ code base, it is much easier to sell that you are just upgrading the compiler to get new language features, that you are rewriting everything from scratch. Now we'll have to see in the next few years if, for new projects, Rust is chosen over C++ wherever it was used traditionally and in which proportion.

I think culture will do its thing here. Getting into C++ now is harder then getting into Rust.

Fantastic observation and concisely put.

I've heard people stating that C is gaining more ground that C++ and it could be for, I imagine, similar reasons.

The poster asks whether new C++ will bring more improvements. It will certainly bring more... "more". And with it, the bar to entry is raised a little more; every new feature designed to resolve some issue or edge-case with a previous addition.

Re: Ask HN: What is the state of C++ vs. Rust?

#77

Post by pjmlp »

Yoric wrote: post #73
bluejekyll wrote: post #29

Earlier quoted context omitted.

Yes, companies that don't want happy employees make these types of monetary decisions. It's their responsibility to their shareholders to do this. It comes at the expense of long-term support of their software though. There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way.

> There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way. I tend to agree with you (and I'm a big fan of Rust), but I'm nearly certain I heard people saying exactly that ~20 years ago. I don't remember which was the language that was expected to replace C/C++, perhaps Java or Obj-C or perhaps some variant of ML. So far, it hasn't quite happened…

Well I believe that if Microsoft had made .NET as they originally were thinking of doing, meaning having .NET Native in 2002 instead of 2016 and not having the internal fights between Windows Dev and DevTools, maybe C++'s role on the desktop wouldn't be what it has turned out to be.

On the Apple side of the fence, C++ was mostly used for IOKit with everything else that wasn't inherited from UNIX, being Java or Obj-C.

Only later on they decided to drop Java, focus on Obj-C and their C++ usage only increased when they decided to sponsor LLVM and move their toolchains to it.

Now we have LLVM as one of the major research compilers available, including for Rust, with all three major desktop companies sponsoring it.

However I think this is probably the area where they will stay, systems programming infrastructure.

Re: Ask HN: What is the state of C++ vs. Rust?

#78

Post by k__ »

zbuf wrote: post #76
k__ wrote: post #42

Earlier quoted context omitted.

I think culture will do its thing here. Getting into C++ now is harder then getting into Rust.

Fantastic observation and concisely put. I've heard people stating that C is gaining more ground that C++ and it could be for, I imagine, similar reasons. The poster asks whether new C++ will bring more improvements. It will certainly bring more... "more". And with it, the bar to entry is raised a little more; every new feature designed to resolve some issue or edge-case with a previous addition.

I think the problem isn't a technical one.

Mozilla seems to put much time into getting the community right, which will get much younger people on board. Then time will do its thing.

Re: Ask HN: What is the state of C++ vs. Rust?

#79

Post by twic »

mi100hael wrote: post #15
agentgt wrote: post #3

This is all personal opinion so take it with a grain of salt. I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative. That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go. If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a g…

> Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, e…

I assumed that agentgt meant "up for grabs" in the sense of "not yet dominated by any one language", which is true. Go and Java are both big presences in that space, but neither is dominant. A language with the expressiveness of Java and the memory use of Go could be a strong challenger, and Rust is already better than that.

Re: Ask HN: What is the state of C++ vs. Rust?

#80

Post by ngrilly »

agentgt wrote: post #17
mi100hael wrote: post #15

Earlier quoted context omitted.

> Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, e…

There are libraries (I didn't downvote you but I suppose that is why as simple googling shows that) [1]. That being said one would argue if you are going the microservices route you shouldn't need an exceptional amount of routing anyway. You only need to really handle raw HTTP for the most part (also I would not say HTTP is the end all for microservices... I have been using a Rust AMQP library with some success [2]).…

When you need to handle a lot of concurrent connections (from your clients, not to your database), Go green threads are invaluable (better than OS threads because a goroutine requires only 2 KB; and better than callbacks). They are also very useful to express concurrent algorithms.
Post reply on HN