Hacker News new | ask | show | jobs
by TimorousBestie 270 days ago
> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language.

So the quest for the one true “modern subset” of C++ continues.

How do developers continue believing in this after a decade of the standards committee proving over and over again that they’re not interested in this and won’t contribute toward it?

3 comments

The article isn't claiming there is a "one true modern subset" of C++ that they use. It's merely pointing out that you can significantly mitigate the main criticisms of C++ by making certain sacrifices, which is pretty much true.

There are good reasons the standards committee doesn't make those sacrifices on your behalf, because ultimately there are tradeoffs there that the programmer is supposed to understand and have control over. However, there is an argument to be had about what the default "safety setting" should be and whether C++ makes a good choice. IMO that's actually the main difference between safety in Rust and C++, since you can make Rust just as unsafe as C++ if you want, only you need to explicitly mark your code as unsafe.

Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.

[1] https://github.com/BjarneStroustrup/profiles

> The article isn't claiming there is a "one true modern subset" of C++ that they use.

They’re arguing that they’ve found a sufficiently safe subset, which if true would be the first.

It would be a waste of time to relitigate the many programmer-hostile, unsafe decisions the committee has made over the years. I think your programmers who are supposed to “understand and have control over” C++’s arsenal of footguns are more or less fictional and a language designer shouldn’t take them as intended audience.

https://robert.ocallahan.org/2017/07/confession-of-cc-progra... (2017)

> Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.

It was discussed at length why this proposal is insufficient: https://news.ycombinator.com/item?id=45234460

Because they are grasping for reasons not to learn Rust.
Their reasoning is reasonable. And besides, when your existing team is already proficient in Cpp, arguing that "they should learn X instead" seems very risky and unwise.
Then just say so and it is fine. We are a team of c++ experts and we are able to build a high quality program in C++ is a completely valid unassailable reason. Except for the most ardent rust fanatic.
Rewriting an existing working codebase rather than committing to its incremental improvement is usually a sign of bad decision making. So I'd be concerned if a team that had an existing mature codebase in C++ and a team of engineers hired on that path were taking on such a venture.

But that's kinda... not a bloggable topic, frankly.

Rust was designed to facilitate incremental rewrites of an existing C++ library, making cross-language testing and validation very ergonomic; why C++ developers rarely take advantage of this (or even account for it as an option in their analysis of alternatives) is an exercise left to the reader.
> Rust was designed to facilitate incremental rewrites of an existing C++ library

Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.

One design constraint of Rust was to be able to be incrementally included in a large C++ codebase: Firefox.

It turns out that this kind of interop with C++ directly is extremely difficult, and so it isn’t super smooth right now. Interop with C was prioritized and you get zero overhead there. And various projects ease Rust <-> C++ via the C ABI.

Mitigate having bad legs by walking on your hands