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

Is it time to retire C and C++ for Rust in new programs?

theregister.com

Post reply on HN
Print view View original

1–10 of 29 posts

Re: Is it time to retire C and C++ for Rust in new programs?

#2

Post by Kelteseth »

As a full time C++ dev I think the biggest argument is missing in this article: The consistent build and package management ecosystem.

With rust/cargo _it_ _just_ _works_. So many hours each month are wasted because of weird linker errors between linker targets, that cannot find a definition of a struct, dealing with broken external dependencies (yes I use vcpkg for that, still happens) and different build tools. I did get better the last few years, but still miles away from what Rust offers.

Re: Is it time to retire C and C++ for Rust in new programs?

#3

Post by rob74 »

What the article completely glosses over is the second part of Russinovich's sentence: "it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required." - now, I know that there are lots of programmers who think that of course, their project needs every last drop of performance the CPU can give them, and are willing to saddle themselves with the complexities of Rust memory management (or the dangers of C/C++ memory management) to get it, but still, it's a good idea to consider if a GC language wouldn't be a better fit.

Re: Is it time to retire C and C++ for Rust in new programs?

#5

Post by MaulingMonkey »

Kelteseth wrote: post #2

As a full time C++ dev I think the biggest argument is missing in this article: The consistent build and package management ecosystem. With rust/cargo _it_ _just_ _works_. So many hours each month are wasted because of weird linker errors between linker targets, that cannot find a definition of a struct, dealing with broken external dependencies (yes I use vcpkg for that, still happens) and different build tools. I d…

There is still the occasional incredibly subtle link time fuckery in Rust.

https://github.com/microsoft/win32metadata/issues/1274

"Minor" semver updates to crates breaking things via e.g. unexpected MSRV bumps is pretty common too, with some resulting bitrot. That said, I agree with you that things in Rust are at least better. Imperfect, but better.

Re: Is it time to retire C and C++ for Rust in new programs?

#6

Post by tayo42 »

Maybe it's close but the ecosystem of libraries needs to mature a lot more from my recent experience working with it.

I found open source stuff is just wrong, or maintained by people who don't have the proper expertise to be writing these libraries. I'm not about to blast anyone specifically but it was tiresome to dig into libraries I would need and find fundamental things I don't think we're right.

A common attitude around performance and handing edge cases. I often hear things like oh well most people don't care about that or your doing it wrong.

It feels like there was a rush of people to try to fill the void that shouldn't have been rushing to write libraries with generic names

Re: Is it time to retire C and C++ for Rust in new programs?

#9

Post by daoist_shaman »

It's time to retire the concept of creating new programming languages to "fix" old ones.

This is software, and it is updateable. We need to stop thinking in discrete terms and start thinking in continuous terms.

If you do not think C and C++ are good, propose solutions to their committees instead of clogging up the digital space with flamebait.

Re: Is it time to retire C and C++ for Rust in new programs?

#10

Post by spotijk »

This feels like how the emergence of Modula / Pascal / Delphi must have felt like. There really was a lot to say for Pascal like languages in the C era.

However, time has not been kind to the early adopters back then.

So I'm inclined to hold out just a little while longer. Let's see if Rust can maintain its momentum.

Post reply on HN