I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years.

With that in mind, "the onus on anti-Rust people is now to demonstrate a better language to rewrite in first, rather than just sitting in the status quo waiting for the steamroller driven by a crab to very slowly run them over." just doesn't make much sense to me. If the status quo is fine, there's no "onus", there's no difficult decision to be made, there just isn't any rewrite. The anti-Rust people will probably be fine by doing ... nothing.

That’s my main gripe with most pro-Rust comments of this kind, to be honest. There are a few ways to write C and a lot of ways to write C++, and most of the C is quite unlike most of the C++. (I’m not counting marginal cases like raw GObject or raw COM as C here, I think those count as basically separate languages.)

The problem is, the Rust I’ve read (and read about) is methodologically and stylistically a replacement for most of the C++, but not a lot of the C. I don’t dislike the theory behind Rust—I’ve written Haskell, I’ve written SML, I read the Tofte&Talpin regions paper and some of the subsequent research more than a decade ago. I do dislike when people ask me to switch or even try to, of all things, shame me into switching from C to what presents itself as a better C++, in largely the same way that I dislike attempts to switch to C++ that claim it’s the same thing as C. No it isn’t. And I largely tune out when I read “C/C++”, because it implies the author does not get it.

(I’m aware there are other people that do get it, some of whom work on other programming languages. They just don’t write posts proposing Rust replace C.)

You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable.

Personally I think something like Rust is helpful for large solo programs too, keeping everything in your head past 10kCLOC is hard so why not have a language and compiler that helps you?

Then, eventually, the company gets bigger and the product needs to grow beyond the capability of one person, so a team starts developing on the codebase. That's where the bugs start pouring in, where everything becomes less consistent, where different design patterns are used all over the place, and where the "single clear vision" gets cast aside. A lot of problems that get blamed on "technical debt" and "brittle code" are often just plain coordination and consistency problems that are happening because multiple people can't share a single consciousness.

I think one problem is believing there exists an "average programmer". It's easy to think in averages (or medians), but the reality is that there is no average person, and exactly one median person.

Realizing that every single person is different is important, because you then start to work in more discrete niches. It's going to be much easier to appeal to "programmers who write X in Y with the following constraints" than it will ever be "programmers who write in Y".

Or to bring this closer to the topic of discussion, you'll never convince game developers to drop C++ in favor of rust using the same arguments as you'd use to convince a service developer to drop C++ for rust.

C & C++ allow quite a few things they shouldn't need to allow to accomplish their goals. They'll never stop allowing those things, so they'll never improve in certain ways.

Rust has a strong backwards-compatibility guarantee, and it has run into this issue with its standard library already. The edition system means the language can break compatibility in some cases, but the standard library can't. I suspect this will eventually prevent necessary incremental change, as it has for C & C++.

That's how you wind up with C++

So many different solutions. Most are preferred because of subjective reasons (although sometimes just poor reasoning period), because people think so drastically differently.

Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks.

Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having to be re-implemented in that language. The only exception are the C/C++/Rust libraries, as these can be used (through C FFI interface) by almost every other language. This is precisely because these languages do not introduce their own heavy-weight runtime (especially: no GC), allowing them to be combined with another language's runtime.

Thus widely used libraries must be written in one of the non-GC languages, even if 100% of the applications using them are fine with having a garage collector.

Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.

It feels like a mischaracterization of Rust and I strongly disagree. Both the language and tooling are designed from the beginning for interop with C code. It isn't very hard to do if you have tried it.

> ... unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers.

This 'Rust is useless if you use unsafe' is a stance that is well debunked, but still gets repeated like this. Ensuring safety using Rust semantics across an FFI with a language like C is impossible - making unsafe necessary. But just because you use unsafe doesn't mean that the language lost most of its advantages. In fact, almost every Rust program uses unsafe code, if you care to look at the code in the standard library. Yet, that never seems to be a problem.

What unsafe does is to cordon off a small code area where certain invariants have to be asserted manually, instead of relying on the borrow checker. You still get the safety for the rest of the code. In case you do get safety violations, there is much less code to debug. This is a significant advantage over languages like C++, considering that unsafe blocks are usually less than 5% of the code, even in the worst case. But to take it further, C libraries often have corresponding Rust wrapper libraries that create safe wrappers over C FFI calls. In addition to the small unsafe blocks to verify manually, these wrappers have the additional advantage of being widely used and debugged by a wider community. There are innumerable such wrappers on crates.io and it's uncharitable to accuse the language of NIH syndrome.

It's not, and you're over indexing on your experience with OpenGL.

There are plenty of rust libs that are thing wrappers over C libraries. They're widely used, without a problem. libgit2, written in C, is the most popular Rust library for git bindings.

Despite that, people do prefer pure Rust libraries for a very valid reason - it makes building the project, especially cross-compiling very easy. That's why cargo audit shifted from libgit2 to gitoxide.

Who is sponsoring the development of these libraries? The Rust Foundation gave the developer of gitoxide grants to develop it, with the eventual goal of replacing libgit2 in cargo.

I'm sorry you had a bad experience with OpenGL, but I don't think it's accurate to extrapolate your experience with that onto the entire ecosystem.

I’m very interested in what you mean here. Isn’t the syntax identical in both cases?

  &array[index]

These are massive problems

    $ emerge -v starship
    <...>
    Running `rustc --crate-name starship --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib <etc>
    Running `rustc --crate-name starship --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin <etc>