What are current possible C++ replacements?

Rust, as mentioned; it was created as a direct replacement to use at Mozilla, among other things.

Zig, which is significantly simpler than C++; good but I'm not sure if it has comparable expressive power (maybe it does, IDK).

D, which is around for some time, but hasn't made inroads comparable to Rust.

Ada, which is around for even longer, and has enough mindshare in certain industries, but sadly not enough generally.

GC-based languages, from Go to Haskell, apparently can't be considered true replacements, even though they are fine for large areas previously dominated by C++.

Nim, if ARC/ORC reference counting is acceptable (which considering I'm using it in embedded firmware right now, it honestly should be, but I can understand why for certain cases it can't be). But it has the same small user-base/lack of inroads as some of the others on your list

Nim does not require you to use reference counting. You can use garbage collection, do manual memory management or not manage memory at all.

I like this flexibility and you can chose the strategy that better fits your needs.

Oh for sure. Though manual memory management does mean giving up a _lot_ of the standard library, and ARC is a brilliant in between.

Though you're 100% correct, its flexibility is what makes it so great in my experience.

Honestly one of the nicest things about it for the embedded work I'm doing is knowing that just about everything I'm writing is boringly stack allocated (minus seqs, strings, etc), exactly like we would've done in C ourselves anyway. But when we need to reach for dynamic memory, then ARC has been brilliant. And having RAII-like destructors I've written around C peripheral libraries has been really nice for reducing errors and making it quick to develop in.

D: has been here for a while but never caught up, don't even looks “new” enough.

Nim: quite old also, but gained a bit of momentum in recent years and even reached version 1.0 in 2019, after 11 years of development. Doesn't looks like it gained much more since then.

Zig: unstable, experimental and used to be developed by a single person, recently gained a small community of contributors. May be usable in 5 years but not earlier.

Ada: has important marketshare in some industries, but even in the said industries its future is uncertain because not many people want to work with it. For instance, in one of the biggest train manufacturer in the world, Ada has been replaced by C in some sectors because hiring Ada people was too hard.

Hare ;)

Object Pascal is a very good C++ alternative that has been hiding in plain sight for quite a while.

Doesn’t Rust place too many limits on what programs you can express to be a viable replacement for C? The premise of C is that you can more or less write any program. Not in the Turing complete sense that is always true, but in the sense that you can make any sequence of memory modifications and control flow decisions and the compiler will produce the corresponding machine code. With Rust, the compiler will only accept a subset of possible and safe programs, the subset that fit in the patterns that the Rust borrow checker can prove are safe.

Rust has unsafe blocks, which let you dereference raw pointers. Also, remember that even in C, if you do something that's Undefined Behavior, the compiler doesn't have to emit instructions that do what you wanted.

If 99% of the time I'm helped by those checks and there is an escape hatch for the remaining 1%, then it's a clear win to have that limit in as many places as possible.

Why would you ever want to wrote something that isn't provable, when you could write something that is?

You always have unsafe blocks for tiny bits of performance critical hardware interaction stuff, but in general, I don't see why we need to be able to access the whole program space in 99% of cases.

Proven by Rust’s borrow checker. That’s not the same as the world of all provably safe programs, which is probably infinitely larger than what Rust will allow.

That's perfectly fine, as long as you can still get the majority of things done in a way Rust can prove.

If removing a large number of possible programs reduces bugs without limiting features, that seems like a win.

>I hope Rust comes out as the winner in the current crop of possible C/C++ replacements

What makes you think C and C++ will be replaced?

I see no systems programming language that's simpler than C and no systems programming language as flexible as C++.

Being that C++ is huge already and its developers like to add features after features, it's almost guaranteed that you can find a subset of C++ that suits the way you like to work.

Your comment seems to ignore all the evidence that shows approx, 70% of security related issues come from those memory unsafe languages. Two independent large companies found that same statistic on two entirely different and large code bases. Google and Microsoft.

You can ignore those findings as you like, but that is why so many people are interested in Rust.

Yet, those same companies are doubling down in C++ for many of their new projects.

Chrome isn't going to adopt any Rust, and Firefox is a few percentilies away to matter at all.

Android now has Rust, yet it isn't exposed to app developers, NDK is all about C and C++, as is the newly introduced AGK for game developers.

AMD/Intel/NVidia now employ many of the ISO C++ contributors and are pushing on using standard C++ as the lingua franca of GPGPU computing.

Azure Sphere, being sold as top security IoT device, has C SDK.

The new WinUI / WinAppSDK are mostly coded in C++, with bindings for other languages.

Apple just released C++ bindings for Metal, as alternative to the existing Swift ones.

So, yeah their business units don't seem to be very keen in following the security advices anyway.

All of those are existing software products, the sunk cost into those is so high that overcoming is monumental. Firefox continues its journey. The better question is what should they do with new software.

The analogy I see is an industry similar to the auto industry as it decides what to do with their ICE based platforms as consumers are going after all electric.

Not really, AGK, Azure Sphere or WinUI/UWP are post the famous security reports.

Regular consumers are going electric when they become cheaper and usable as ICE vehicles, until then they are fine for rich people with garage.

People tend to forget that we use those languages, because the gatekeepers of certain platforms only offer them as supported option, with nice tooling and libraries.

Naturally one can bring others into the game, when they are willing to replace the platform owners in the whole stack beyond a bare bones compiler.

I don't see any reason a language needs to be simple, as long as the abstractions are close enough to zero cost. Since Rust can run on even 8 bit microcontrollers, it should be able to replace C in a lot of places.

There might be some set of tools out there that will make C++ as safe as Rust(It seems like some are talking about borrow checkers but finding it near impossible?), but Rust is designed for safety from the ground up.

Plus, even if your linter catches 100% of bugs, your libraries probably won't use those standards, and may be full of bugs.

Not that you'd ever do a JS-level amount of reuse in C, since the lack of standardized package management sometimes makes it not even worth it to use a library, almost like they actively want to discourage reuse.

Rust has a problem with some things being community that should be stdlib, but standard practice in C++ seems to be to reinvent way more wheels than other languages.

Here for some borrow checker like information,

https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...

Memory safety just isn't going to be optional in most contexts. Whether you achieve it by a GC, borrow checker etc will be the option.

> I see no systems programming language that's simpler than C

I guess that depends on what "simple" means

People always think the next language, framework, paradigm, etc is going to solve all their problems. It's a pipe dream. You can write garbage in any language.

>You can write garbage in any language.

That's why some runtimes have garbage collectors.

You can write less garbage in some languages (eg no memory safety bugs in safe Rust), or at least make it more difficult to write that garbage

Some people don’t understand that reducing bugs and eliminating entire classes of bugs is progress. Their “gotcha” is that it’s still possible to write logic bugs, and therefore what’s the point of any language improvements?

You can still write memory safety bugs, you just need unsafe. I'm glad unsafe is used in so many libraries.

Libraries are where unsafe belongs. Having unsafe be an explicit feature is immeasurably better compared to every line in the entire program potentially being unsafe.

Opting out of safety is fine, but safety must be opt-out to be effective, not opt-in. A standard, enforced way to tell readers where the dragons lie is super helpful.

Right, note that I said safe Rust, which is the vast vast majority of Rust out there. This is a major improvement over, say, C, where any line of code could be potentially unsafe.

In sufficiently strict languages you can only write garbage specifications.

Well, they solve some problems.

> And if we don't stop making critical security errors, there could really be a movement to return to analog tech, big enough to set us back 10 years

I'm very curious about the world you live in. Security of IoT is literally the last concern of pretty much everyone I know. The ambient sentiment is "Alexa/Siri/Google is already listening to everything we do anyways".

Privacy isn't anywhere near my list of concerns(At least not for myself personally), but the people who do care, care a LOT.

And even beyond privacy, those people don't like the idea of dependence, not learning paper arithmetic and handwriting, etc.

There are also the rare insane ecofascist types who think technology is unsustainable, and we need to drop it all(And then just let people die until the low tech becomes sustainable...).

A lot of people have a certain amount of respect for Kaczynski in some communities.

Lots of people hate vegetarianism without making any claims at all about the health, they just say it's unnatural, and that's enough reason.

I think there's enough people who really would enjoy a computer-free world to make it a trend to boycott this stuff.

I've always thought that Apple is actually largely an anti-tech company.

While in some cases they do have some excellent high tech under the hood(M1 and their zeroconf network protocols), their aesthetics is almost Bauhaus-level minimal, and the feature set is often randomly reduced(Like the one port laptops).

Their UI is very gestural, involving muscle memory and a feeling of "flowingness" not "proceduralness".

There's a slight sense of "You're smart and capable, you don't need to be a tech person and hide behind a computer, you don't need everything to be perfectly compatible, it's fine if some features aren't perfect" in their restrictive app policies and unique connections.

It's not quite "Star trek dream", where no matter what happens, tech is a point of trust that you expect will adapt to get you out of any jam. They want it to be an appliance or luxury piece of furniture. A multi purpose one, sure, but you're supposed to feel like you'd be just fine without your iPhone.

Sure, everyone has a Siri... but it seems like about half love them, and the other half wish it was easier to just live off grid.

>So many people don't trust computers

Mostly that's for reasons unrelated to the class of bugs the Rust compiler prevents.

I wouldn't trust Google or Facebook more if they were using Rust. :)

The reason people don't trust "computers" has nothing to do with bugs in the code lmao. It has to do with the fact that they inescapably track their every move and fuck with their minds to completely inscrutable ends.

That shit is basically working as intended, a stricter compiler is not the solution to it.