Hacker News Reader

Comment by galangalalgol | Hacker News Reader

Are there really any good reasons to start a brand new project in c++ though? No one who can write modern c++ has any trouble with rust in my experience, and all the other common options are even quicker to pick up. Creating bindings isn't hard anymore if your niche library doesn't have any yet. Syntactic preference I guess, but neither c++ or rust are generally considered elegant or aesthetic choices.

View on HN

Because "brand new" doesn't mean devoid of context. Within your domain, there will still be common libraries, interfaces, and tools.

C++ is very flexible, with a lot of very mature tooling and incredibly broad platform support. If you're writing some web server to run on the hardware of your choosing, then sure, that doesn't matter. But if you're writing something deeply integrated with platform/OS interfaces, or graphics, or needs to support some less common platforms, then C++ is often your only practical option for combining expressiveness and performance.

This is the sort of info I was trolling for, but what are those platforms and os? Targets llvm doesn't handle yeah c++ makes sense, or c. A sibling mentions xcode, which makes sense. Graphics seems questionable, vulkan support is fine. Windows support has seemed finetoo, the same gui has worked as what we wrote for Linux.

Dependencies. There are billions of lines of C++ out there that have been optimized and production hardened over decades that you might want to reuse. Rust lang interoperability with anything but C sucks in practice.

Unreal, Godot, CryEngine, DirectX, PlayStation, Switch, XBox, CUDA, SYSCL, LLVM, GCC, V8,...

Maybe, maybe not. But either way it's just plain rude to charge into a C++ thread to drop a comment saying how the language sucks and you should use (insert other language) instead.

Yes, there are plenty of domains where Rust has zero ecosystem.

Not to mention that Rust advocates keep forgetting their compiler is partially written in C++ (LLVM/GCC).

Rust becomes a significant burden if you need a GUI or hardware-accelerated graphics.

C++ isn't much better for GUI.

I assume most of them are just grabbing qt

C++ was the GUI king during the 1990's, and none of the Rust toolkits is half as good as the surviving frameworks, like C++ Builder, Qt, wxWidgets, heck even MFC has better tooling.

> wxWidgets

I'll trade you wxWidgets for FLTK.

Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it.

FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.

In addition to other reasons given: If you have a team of C++ developers, let them use the language they know best.

Yes. If you're targeting Apple platforms and want to allow clients to use your product in Xcode (the common case) or even need Swift/ObjC interop yourself, using rust or anything not explicitly supported by Apple and Xcode is just too fiddly.

Why not pick swift in this situation over c++?

(Shrug) If I want Rust, I'll feed my C++ to an LLM and tell it to port it to Rust. Since we've been assured that Rust magically fixes everything that's wrong, bad, or unsafe about C++, this seems like a sound approach.

We probably aren't that far off actually. Even taking asm with no symbols back into rust works well. You have truth, just have the agent repeat until the asm matches. Doesn't work on giant codebases, but on a few functions it absolutely does. And while the llm may get the algorithm wrong, the type system does seem to help it generate useful code in rust for a starting place v

Yeah, but then just let the agent generate proper C++ code, contrary to an human it doesn't forget about best practices, or how ownership is supposed to be handled.

Except the llm forgets about that in rust too, then the agent looks at the ownership errors from the previous iteration and fixes them.

First it needs to have a Rust ecosystem available, e.g. CUDA, SYSCL, HFT, HPC,...

Maybe it could be used to remove Rust dependency on C++ infrastructure (LLVM/GCC), and bring Cranelift up to speed.

You missed the other take, with AI assisted coding, you can stay in C++, as it will take care everything is coded with enough care.

Or why bother with Rust, when the LLM gets to generate C++ code with best practices.

While I like Rust, I think AI as the next abstraction step in programming has kind of taken its relevance away, when computer assisted programming is part of the workflow.

Strange. I wouldn’t trust the output of a coding agent and I would want stronger review of its output. If it passes a strict compiler that gives me more confidence than if it passed a lax one.

But sure, if you trust it to have written C++ to a higher standard than the experts, then go for it.

So not into the vibe coding hype taking over all our jobs?

It is what it is, I accept that’s where the industry is heading.

But if I have to produce reams of code I’d much rather have it be reviewed by rustc than clang. rustc may take longer to satisfy, but it’ll be worth it because I won’t be responsible for horrors in production.

You’re happy to be responsible for buffer overflows written by an LLM? I’m not, which is why I prefer a language where it’s not possible.

It is definitely possible, only not as easy.

Even reviewing human written C++ is difficult. Android has had 20 years to figure it out and they couldn’t find a way to reduce the number of vulnerabilities they introduced in carefully crafted C++ code. I shudder to think how many more they would have introduced if they had vibe coded it.

Yeah, good point, I don't know how I missed that possibility.

/s of course... for now, but not for long.

Reply on news.ycombinator.com