Hacker News Reader

Comment by scotty79 | Hacker News Reader

Honest question.

If I want to spin up a new project with a coding agent to explore some idea and I'd like the bare metal performance, why would I choose C++ over Rust?

I could choose TypeScript over Rust if I wanted it to be html first or I could choose Go if I wanted it to be clear of the complexity of memory management or I could choose C# if I wanted it to have best interface with windows stuff or I could choose something Erlang VM based for resilience and multithreading.

But what reason might I have to pick C++?

View on HN

Interfacing with other C++ projects or leveraging existing infrastructure/work you've done.

Rust's package management and lack of stable, high-quality libraries maintained by professional or even just generally known entities are a pretty big problem. For the small number of Rust projects I've attempted, I've tried to make them zero-dependency, and it worked (you just ask agents to implement more libraries) but it added a lot of annoying overhead.

It's also just easier to write high performance code in C/C++. If you'd rather have that than builtin memory safety guarantees or whatever else you want out of Rust, or have a small enough surface for errors/threats that you can just manually spend time validating that your code is safe and secure, C++ is still pretty good IMO. I would generally start with C though, because it makes interop with other languages easier

> Rust's package management and lack of stable, high-quality libraries maintained by professional or even just generally known entities are a pretty big problem.

IMHO, Rusts package management is the opposite of a problem.

And a lot of stable high quality crates exist, such as Tokio, thiserror, chrono, axum, .......

I have nothing but respect and warm feelings for developers who choose to create and maintain software packages and make them available for others.

The problem is that I need to be able to trust my dependencies' provenance. Not just that the developer is good, but that this particular version is good, and that all their dependencies are good and that their versions are good. If there is a security issue in something I use, I need to know that the people responsible for maintaining it have the time and resources to be aware of the problem, quickly patch it, and make the fix available to me; because of that, I also need to regularly check my dependencies' new versions for security fixes and upgrade to them as patches roll out. But I don't have the time to closely review or investigate all of those, so I need to trust that they're handling it without knowing them personally.

Worse, if there is only a single or small group of part-time maintainers handling a package, it would be very easy for a malicious release to be made either unilaterally for financial gain, or unintentionally by some credential hijack (some script pushes a new minor version, they might not notice), or a supply chain hack (eg their build environment got pwned->the software they distribute is not the software they intended to send).

So I prefer to only use 1P packages, dependencies from a well-resourced brand or known figure with something to lose, or dependencies I know very well (and I only have time to know a small number very well). Has nothing to do with the quality of the packages or the developers' skill.

> But I don't have the time to closely review or investigate all of those, so I need to trust that they're handling it without knowing them personally.

so either you pay someone to do the work for you or you hope that someone does it for free?

yeah that's basically my point. People who maintain crates don't work for me and it wouldn't be reasonable to assume any kind of responsibility for keeping my stuff secure, unless there was some big fancy standard library or runtime pushed by a major corporation or public figure that was committed and capable of doing so. So I implement my own rust libraries (just the parts I need, mostly asking agents to do it) because it's the most cost effective way for me to trust my supply chain.

But I wouldn't have to do that as much in languages with larger standard libraries or more established libraries/tools/ecosystems (eg abseil in C++, numpy and tensorflow in python).

If a coding agent is writing code for you, telling it what language to use is micromanaging. It might use Rust, it might use C++, it might use both. If it's writing the code, it probably has a better idea than you have for what's appropriate for that code.

When I didn't tell it what to use, recently it used VB (mixed with Python). Not ideal.

Only if you don't intend to maintain, debug, or even understand what the code is doing.

Or at least not without the benefit of more capable coding agents than you used to create it.

And only if the coding agents in question can be trusted to not deliberately or accidentally fail to provide you with critical information ("Now that you mention it, the program does occasionally POST the contents of ~/.aws/credentials to a web server. As this produces no output, I didn't consider it relevant to your question about whether it correctly outputs the string 'hello world'.").

Maybe you don't. If you were to spin up a new project with a coding agent most of the subsequent highlights of the languages you cited might also not matter.

Reply on news.ycombinator.com