Comment by spoiler | Hacker News Reader

Comment by spoiler | Hacker News Reader

Parent Full thread

I can't help but feel like he's missing the point a bit. Sure, you can get a few Rust features in C++ if you (1) stick to specific syntax forms or else tools can't detect stuff or report false positives (2) use a collection of third party tools that work together by accident more than by design, so they end up being glued together differently in each project, and (3) they're not part of the language.

I've not worked with Visual C++ much (used it once and thought the CLI pointers were a cool feature, though), so maybe that's better. However, my experience on Linux has always been… Uncomfortable? I don't know what to call it.

Sure, all of these things kinda and almost work. Technically they make things marginally better. So, he's not wrong, but only by the strictest possible definition of "wrong". And Jesus Christ, they always made me feel like I stepped into a time machine and traveled back 30 years (and I'm only turning 30 this year), and induced so much friction into both set up and workflow.

Rust on the other hand? I don't have to think about it any of those, and it borrows (no pun intended) great FP type system features to boot.

Also, I don't know what went wrong with C++ Concept, but I was excited about them initially, and now I'm just underwhelmed by them. The coroutine stuff is also a bit frustrating.

C++ is a language that has jaded me with a thousand small frustrations over the years. I still have a small hope that it'll one day rebound (as I used to write it for a long time), but in the mean time I'll stick to Rust.

Also, since he's deliberately chosen to be petty about memory safety in Rust, it probably doesn't warrant addressing, but I'll take the troll-bait this time: nobody EVER said memory safety is the ONLY safety. Ever. I've not seen a single person make that claim, or tout Rust as a "safe" language. Memory safety DOES however eliminate a whole category of bugs (a lot of which can be security or stability bugs in real world environments). That's literally all there is to it.

Edit: my experiences predate a having a Cpp LSP that works (idk if that has changed in the last few years)

He kind of does, in the sense that stuff like span do require opt-in configuration for bounds checking, and both clang-tidy and VC++ Core Guidline checkers still leave too much room for improvements.

I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care.

Which is also visible in surveys like the ones published by JetBrains, where unit testing and static analsys tooling never get that high.

> I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care.

I don't agree, specially considering legacy code. Those of us still have to deal with an awful lot of code written 10 or 20 years ago still have to maintain code that juggles pointers and references around in ways that are hard to track ownership, and migrating this code to C++11 is no simple task. This doesn't mean people don't care. It just means the industry cannot afford getting whole teams to spend a couple of years on sabbatical to refactor legacy code and pay it's legacy debt.

This is perhaps the biggest strawman that Rust fanatics use to criticize all things that isn't written in Rust. They pick their small little greenfield modules and boast how safe and perfect it is, and proceed to criticize all legacy production code whose teams can't even spare time to fix long standing bugs, let alone pay off technical debt. And that's somehow something Rust fixes?

This security fanatic keeps seeing greenfield code written exactly like that, today.

I also preach against "C with C++ compiler" since around 1994.

Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.

> Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.

See, this is yet another instance of the strawman argument I pointed out.

This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things.

Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.

With enough liability laws, the resource allocation gets sorted out.

Of course there are exploits in safer systems languages, memory corruption issues and arithmetic exploits only represent 70% of root causes.

We still need to consider the remaining 30%.

Can you give concrete examples?

They can't. Rust has been way more secure than C++ in the wild.

Sure, the language hasn't been around for that long, but that doesn't invalidate the fact that there are large codebases written in it, and that maintained projects in Rust regularly keep up to date with language advancements, though.

Another benefit of Rust is that you can largely avoid the same category of monster codebases common in C++, because there's much less (virtually none) friction in splitting up your codebase into crates.

Like SURE... You CAN do this in C++, but it's usually just simply not worth the bother, because you gain next to nothing

> however the production code I get to occasionally look into proves that a large majority just doesn't care.

In part, I think the issue you described is that usually with C++, the correct solution is the more obscure one, and usually much longer and sometime even harder to parse (by a human), while the incorrect (or less correct) solution seems idiomatic and obvious.

I think this would probably not have been an issue if the language shed baggage as it evolved.

Maybe this already exists, but having ways of enforcing that only subsets of languages would be useful for their evolution. All languages have baggage and complexity starts to increase as there can be many different ways to do the same thing. The response is to create new ones as a kind of pruning effort.

If is were possible to use a language subset (C++ indigo or something like that) that only allowed a certain subset it (along with toolchain support) would help since at least new projects and libraries could strictly conform to that. Similarly old code bases could be migrated over time.

> Rust on the other hand? I don't have to think about it any of those, and it borrows (no pun intended) great FP type system features to boot.

I think this is the real value. As an analogy, I once updated a large legacy codebase from Java 1.x (pre-generics) to Java 1.5+ adding generic annotations everywhere. It took many months of incremental, interspersed work. In the end, there was exactly 1 bug uncovered where a drop-down list would rarely show `ObjectType@addr` instead of the proper rendering which was otherwise harmless.

This is to say that the added type information wasn't mainly needed to reduce bugs as it's raison d'etre, but that it meant that developers had reduced cognitive load of types while working.

I was in college during that transition, and keeping track of which classes I could use generics in and which I couldn't was a real pain...

Reply on news.ycombinator.com