> C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time.

Nobody denies this, which is why one of Rust's main goals was supporting the C ABI, so Rust can use existing C libraries, or an application written in C can use Rust libraries.

> Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021.

I am curious. Could you give some more context?

> Get a build system that's easily workable without an Internet connection and recent TLS support.

Cargo supports vendoring dependencies and local dependencies.

> Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU.

When has it even been easy for beginners to build out systems infrastructure?

Progress is being made on allowing Rust to target more platforms, including `rustc_codegen_gcc` and `gcc-rs`.

> I am curious. Could you give some more context?

Probably talking about this: https://github.com/pyca/cryptography/issues/5771

> If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU.

C is welcome to that niche IMO. The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet; if Rust can replace those use cases then it'll be job done.

Most of those applications would probably be just fine with a GC language, so the cognitive load of doing things safely in any non-GC language is probably a waste.

Sure, but given that even today people still feel the need to write applications in non-GC languages for some godforsaken reason, it's good that Rust is there for them. Making a new language is easier than educating the developer population, sadly.

Most of them might be fine in a GC language, but most of those GC language apps will bind to C libraries as some point. It’s those underlying components we need to start to replace for truly robust systems.

> The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet;

But I think this is already been taken care of by Java and others?

> Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86

Anecdotally, I had the same issue recently with a C++ tool I wanted to tun on arm linux (forgot what it was; but it was a WASM tool. I ended up using a Rust alternative that was less mature, but did all I needed anyway)

Lastly, the issue you're describing is more of a DevOps one. C++ has a longer history, and one would hope it has accumulated more DevOps wisdom over that period of time.

"one would hope it has accumulated more DevOps wisdom over that period of time"

Yep. My thoughts exactly.

It's not like it's any different for C. Rust gives you a choice of five operating systems? A given C library gives you a choice of one, on a good day. And if you've got your favorite C library already then binding to it is a breeze. I don't understand the mindset that because Rust and its entire ecosystem is less than perfect it should be junked for C which never even cracked a quarter of the distance.

> beginners

> OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU

what?

The fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs.

Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.

C/C++ target a fragmented mess that's different on every platform and inconsistent across projects. Technically you can invoke rustc the same way you invoke cc, and craft makefiles and handle all your dependencies the old way, but it's so tedious and fragile compared to Cargo that nobody wants to.

It's also possible to have simple enough C and C++ packaging. A lot of the problem is just inertia and education. But a lot of the problem is also that C and C++ are designed (if only implicitly) to work in all kinds of contexts as a feature.

Nope, C and C++ target the C and C++ ecosystem. If that’s the ecosystem you have then presumably that’s because your a C or C++ developer and that’s what you’re used to. Personally I find installing C and especially C++ libraries a massive pain.

I can't speak to your experiences, but there isn't one C or C++ ecosystem. It's common to write C or C++ to target: ruby, python, Java, Linux distros, C++ package managers, numeric analysis ecosystems, OS kernel development, embedded ecosystems, game ecosystems, robotics, wasm, and JS ecosystems. And I'm positive that's not a complete list.

...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic?

There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point.

And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortran that calls C. Replacing arbitrary layers with Rust is technically possible, though Rust doesn't tend to be deployed in situations like that, at least not yet. I'll consider the Rust ecosystem more mature when you see Rust used mixed ELF situations like that.

"There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point."

Yep. The Rust ecosystem is very much a product of the always-connected, move-fast-and-break-things, DevOps-CI/CD-SCRUM-Agile, horizontal scaling world... which is fine right up until the point where it needs to be used outside of that world, at which point all hell breaks loose.

Rust-for-Linux doesn't use cargo, yet no satan or demon appears anywhere. Yes, adding dependencies is not single line updated like Cargo-based workflow, but also not that much different than adding a C/C++ dependency.

Update:

Based on the comments here, I see that I need to clarify two things, as edits are locked.

First, I actually happen to rather appreciate the Rust language itself. It is both powerful and pragmatic, and has quite a bit to recommend it. Even in situations where its addition has been personally very problematic for me (e.g. Firefox), I can still tip my hat to the added value. What I take strong exception to is Rust evangelism, i.e. the idea that Rust and its ecosystem are clearly superior to all other options in a given use case, and any person using other options must be either insane or uninformed. This represents, at best, a very narrow view of the computing ecosystem in the 21st century. My comment is a rebuke of the evangelism, not the language.

Second, the term "rusties" might have (reasonably) seemed like a label that I applied to any Rust developer. This is not the case, and the perception is a result of my failure to clarify. There is a particular class of person whom one meets, with whom any discussion of any technology project inevitably leads to "well you really should write that in Rust." Such folks- overzealous Rust evangelists- are "rusties" in my vocabulary. If that describes you, feel free to take insult if you like. If that doesn't describe you, then my apologies for any misunderstanding.

> Get a build system that's easily workable without an Internet connection and recent TLS support.

I'll say typing `cargo build --offline` can qualify as "easily workable".

How do you vendor to local, without the recent TLS support?

Copy it over from a normal computer.

with an USB stick? like an animal? /s

> Rusties

please don't

Isn’t the whole shtick with programming language devotees that they have names for themselves like Rusties and Gophers and whatnot

I use both of those, and I would just say "I use Rust and Go". I don't think "Rusties" is appropriate, unless you are 13 years old.

Can’t be worse than “Rustaceans.”