We Ran Our Own Infrastructure
Another revisionist myth. SourceForge (the first forge!) wasn’t “our own”, nor was BitBucket (mentioned by author), or Gitorious (which was famously archived btw). or sourceware, or …
I guess we can call ftp servers like the gnu ones “ours”. But that’s about it as far as where congregations of relevant projects lived.
Did some projects self-host with trac, cgit, mailman, …etc? Yes, of course. Just like how some projects self-host today with gitea/gitlab/…etc.
Here’s a 249-page book “just” about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it’s a terrible language? No
If that book was about a million ways of how to just use atomics in Rust, then yes, that would be potentially bad. But SURPRISE SURPRISE, it’s not. As you can see for yourself.
Not sure what you were getting at there. Even hard C++ copers don’t attempt to argue against the fact that C++ is huge, and not only that, it’s the biggest language around by an easy margin (this can be roughly and superficially measured by comparing spec sizes).
It’s not the size, but rather everything on top of it, and contributing to it, from general incoherence to bad design to countless misfeatures, that require non-trivial argumentation.
C++ and JS are objectively shit languages from the pool of used languages.
What you quoted is one of the many COPEs Bjarne used in his lifetime. Because unlike JS people. who admit that JS is shit that was originally hastily put together, Bjarne needs the C++ bureaucracy, and the facade of superiority (even if it only lives in his own mind), to keep going because he has nothing else to show for.
Or to avoid ad hominem accusations:
No code. Don’t Care.
And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.
People stopped taking Brian seriously when he helped create Go. That was pre-Rust.
Even the “talking points” here seem to be re-used from “Go vs. X” ones. Also, his experience speaks of someone who only tried Rust pre-v1.0.
Anyone who actually knows Rust, anti- or pro-, knows that what he said (partially in jest) is factually wrong.
Feel free to prove otherwise, especially the part about the performance of Rust programs. Don’t be surprised if he simply didn’t pass --release to cargo build, a common pitfall for someone in the “hello world” stage of trying Rust.
And this is why appeal to authority was never more fallacious, considering we live in a world where Dunning-Kruger is a universal reality.
There is no substitute for the static analyzer within the compiler informed by the type system. Near-zero bugs require provable static analysis that guarantees preventing a certain bug class, i.e. (safe) Rust for the bug classes it guarantees preventing. Hopefully, future languages with even better type systems will help with even more bug classes, or incrementally improves on what Rust currently has to offer.
C code simply doesn’t have enough info for an external tool to push bugs down to near-zero count. This is also exactly the point of struggle that lead to complete failure in delivering guaranteed safety to C++.
There has been murmurings, mainly from non-technical people, about how “AI” will render advancements in safer type systems nearly useless, because the magic (mushroom) AI will just find all the issues in code written in older languages. What they don’t realize is that the effect will be reversed. Many established projects that come with a high reputation, and a veneer of maturity, indestructibility, and meticulousness will simply, and perhaps unfairly, lose that perception under the continuous barrage of potentially high impact bugs and vulnerabilities surfaced by these tools, with not enough human bandwidth to keep up with them, and with new code susceptible to the same problems repeating over and over. This will effectively lead to an even harder push for adopting technologies that prevent a good chunk of these bugs from ever happening at any point, not the other way around.