But the us is China's market, so the ccp goes along even though they are the producer. Because a domestic consumer economy would mean sharing the profits of that manufacturing with the workers. But that would create a middle class not dependent on the party leading (at least in their minds, and perhaps not wrongly) to instability. It is a dance of two, and neither can afford to let go. And neither can keep dancing any longer. I think it will be very bad everywhere.

Poking around it looks like ada is actually the minority now. Everything current is either transitioning to c++ or started that way. The really old but still used stuff is often written in weird languages like jovial or in assembly.

Essentially the story of DoD mandates goes down to everyone getting waivers all the time and nuking the mandate.

Not to mention embedded software is often half the pay of a startup and defense software often isn't work from home. Forget asking what languages they can hire for. They are relying on the work being interesting to compensate for dramatically less pay and substantially less pleasant working conditions. Factor in some portion of the workforce has ethical concerns working in the sector and you can see they will get three sorts of employees. Those who couldn't get a job elsewhere, those who want something cool on their resume, and those who love the domain. And they will lose the middle category right around the time they become productive members of the team because it was always just a stepping stone.

How does it do on things that were originally written in assembly?

This is typically easier because the code was written for humans already.

Doesn't the ease and low risk of individual copyright violation place an upper bound of sorts. Sharing sites are still everywhere, and they were never very successful in making people confuse civil for criminal.

The rant from 12 monkeys was quite prescient. On the bright side, if the data still exists whenever agi finally happens, we are all sort of immortal. They can spin up a copy of any of us any time... Nevermind, that isn't a bright side.

“Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?”

what a great comment :)

Stars, issues closed, PRs, commits, all are pointless metrics.

The metrics you want are mostly ones they don't and can't have. Number of dependent projects for instance.

The metrics they keep are just what people have said, a way to gameify and keep people interested.

So number of daily/weekly downloads on PyPI/npm/etc?

All these things are a proxy for popularity and that is a valuable metric. I have seen projects with amazing code quality but if they are not maintained eventually they stop working due to updates to dependencies, external APIs, runtime environment, etc. And I have see projects with meh code quality but so popular that every quirk and weird issue had a known workaround. Take ffmpeg for example: its code is.. arcane. But would you choose a random video transcoder written in JavaScript just due to the beautiful code that was last updated in 2012?

It is fine if a dependency hasn't been updated in years, if the number of dependent projects hasn't gone down. Especially if no issues are getting created. Particularly with cargo or npm type package managers where a dependency may do one small thing that never needs to change. Time since last update can be a good thing, it doesn't always mean abandoned.

The issue with safer c++ and modern c++ is the mirror of the problem with migrating a code base from c++ to rust. There is just so much unmodern and unsafe c++ out there. Mixing modern c++ into older codebases leaves uncertain assumptions everywhere and sometimes awkward interop with the old c++. If there was a c++23{} that let the compiler know that only modern c++ and libc++ existed inside it would make a huge difference by making those boundaries clear and you can document the assumptions at that boundary. Then move it over time. The optimizer would have an advantage in that code too. But they don't want to do that. The least they could do is settle on a standard c++abi to make interop with newer languages easier, but they don't want to do that either. They have us trapped with sunk cost on some gaint projects. Or they think they do. The big players are still migrating to rust slowly, but steadily.

There kind of is. There's __cplusplus, which I'll grant you is quite janky.

  #IF __cplusplus==202302L

That checks whether a C++ compiler is used and, if so, for the version of the compiler, not whether “only modern c++ and libc++ existed inside it”.

C++ compilers carry lots of baggage for backwards compatibility.

I'm wondering if the C++ -> Rust converters out there are part of the Solution: After converting C++ to Rust, then convert Rust to C++ and you now have clean code which can continue to use all the familiar tooling.

> I'm wondering if the C++ -> Rust converters out there are part of the Solution

Are there C++-to-Rust converters? There are definitely C-to-Rust converters, but I haven't heard of anyone attempting to tackle C++.

> After converting C++ to Rust, then convert Rust to C++ and you now have clean code which can continue to use all the familiar tooling.

This only works if a hypothetical C++ to Rust converter converts arbitrary C++ to safe Rust. C++ to unsafe Rust already seems like a huge amount of work, if it's even possible in the first place; further converting to safe Rust while preserving the semantics of the original C++ program seems even more of a pie in the sky.

Presumably you migrate to this Rustic++ version implying it's maintainable.

I'm not questioning what you do once you get to that hypothetical Rustic++. I'm questioning whether it's possible to get there using automated tooling in the first place.

I think you have a point. Rustic++ won't be vibe-coded in a weekend.

> There is just so much unmodern and unsafe c++ out there. Mixing modern c++ into older codebases leaves uncertain assumptions everywhere and sometimes awkward interop with the old c++

Your complaint doesn’t look valid to me: the feature in the article is implemented with compiler macros that work with old and new code without changes.

See https://libcxx.llvm.org/Hardening.html#notes-for-users

Thats true, going bottom up is easier. Old c++ making calls into modern c++ or rust is less of a problem than the other way.

And not everywhere, as there are many industrial scenarios where Rust either doesn't have an answer yet, or is still in early baby steps regarding tooling and ecosystem support.

At this point it likely helps the defenders more than those that would use them doesn't it?

It already did happen. It propogated via build.rs as well. But as I said elsewhere, ut doesn't help you to forgo dependencies part of rust tooling itself.