Hacker News Reader

Comment by testrun | Hacker News Reader

Not a fan of where this is going. Just use Rust instead. All this is doing is making c++ even more unmanageable. When developers are pressed for time they will revert to what they are used to and know. What you get in the end is a mess of code with different ideas at different parts of the system because they are developed at different times by different people. Or you are going to put down very strict guidelines and redevelop everything according to these guidelines. Then you are back to rather use Rust instead. The guidelines is built in the Rust language.

View on HN

Clearly, this is not for you.

I work in video games, most games use Unreal Engine, most existing toolsets and dependencies are built on C/C++, I have 17 years professional experience and nearly 30 years including hobbyist experience in C++. I often think I'd start new projects in Rust, but the last two large personal projects I started in C++, and one of them has been deployed in iOS, Android, Windows, Linux, Mac, WASM and RPi environments without much trouble. I haven't regretted that choice, even though I do really like Rust. In my contracting work, Rust just isn't an option. In my personal work, Rust is an option but since C++ has been getting better, I see less and less reason to use Rust.

But, you, please keep using Rust. It's a great language and I hope it someday eclipses C++. C++ was never designed as a cohesive language (Bjarne said exactly this in a talk I attended), it was designed as a grab bag of ideas, and I believe much of what's bad about C++ stems from that philosophy. Rust is built from the ground up with good ideas. But there's nothing wrong with improving C++ for those of us who it's really the best or only option.

EDIT: To be clear on this particular article, I agree it's not a great direction. But "just use Rust" is not helpful, and you may not have the problem this is trying to solve.

This is for corporations with 40 years of code in production, that hardly do greenfield development.

How will Rust look in 40 years, if it reaches thus far?

When will rustc stop depending on a C++ compiler construction framework?

This is pointless for corporations with 40 years of code in production.

Changing all those 40 years worth of code to the safe subset is equivalent to a total rewrite. Especially since usually the really old parts of the code have never been touched or modernized, so are usually C-like and therefore very far away from the safe subset.

One might as well rewrite it in something properly memory-safe.

Those same corporations have made the transition from C to C++ during the 40 years.

They aren't going to do the same with a complete reboot.

It is the same reason why from all JavaScript wannabe replacements, including WebAssembly ones, Typescript is the one that got the price.

That transition from C to C++ isn't really the same kind of transition. When moving over to C++ from C, you get to keep and use all your old code and gain new capabilities for the newly-written parts. Extending stuff like this is easy.

Moving to a subset is very hard, because you loose capabilities. And since this is about memory-safety, you either loose them all at once, or you aren't really memory-safe until you migrated all your codebase to the subset.

So while C->C++ takes 40 years, you get benefits in pieces during the 40 years of migration. With C++->SafeC++, you can only get those benefits at the end of those 40 years. Which usually means that it won't be done at all.

What might be a possible approach is to divide a huge codebase into smaller parts, isolate them from each other (microservices if you want to call it that) and then migrate those smaller parts to SafeC++. But since that would change the whole architecture of the codebase, the viability is always a very big "maybe".

> you aren't really memory-safe until you migrated all your codebase to the subset.

That's true for every gradual migration, even to another language. At the limit any rust code that uses 'unsafe' is not really memory safe for small values of 'really'.

Perfect is the enemy of good. An incremental improvement to the status quo is still an improvement.

Although I'm firmly in the "I'll believe [the practicality] when I'll see it" camp, I'm all in favour of these experiments with memory safety.

It is still much easier to sell than throw away, rewrite in Rust, while the ecosystem is full of growing pains, and not yet taken seriously in many industry critical standards.

I agree that this proposal isn't great. But also that you're not responding to what the comment is really saying - it's responding to the "just use rust" suggestion. If Rust is a good choice, great. But that doesn't mean we should abandon all attempts to improve standardization of C++. And I mean "attempts" - production conversation should be around why something doesn't work and why it fails, "just use rust" is not really relevant here. It's perfectly fine to say when starting a new project or figuring out how to rewrite an existing codebase, but in a conversation about C++ standards it's just not relevant.

I like Rust and very happy it's being used more and more. I am just tired of it constantly coming up in any talks about C++ on HN.

Especially when building the Rust compiler, at least for the time being, requires C++, and many domains Rust wants to play only have C and C++ based industry standards like Khronos APIs, CUDA, consoles,...

> When developers are pressed for time they will revert to what they are used to and know.

Is not being able to do this a great selling point for Rust? It's better to have nothing instead of code that may have a bug?

I agree, with the slightly altered advice: just use Swift instead

And ignore vast majority of computers? And suffer with Xcode?

Swift runs on windows and linux too. It’s not limited to Apple devices by any means.

Reply on news.ycombinator.com