People often point this out, silently implying that Rust is not really supported/usable on the lower tiers and that therefore those platform should stick to C. But that's ignoring that the situation is the same with gcc/clang: niche platforms get much less testing, and very niche ones might have bitrotted without anyone noticing. Gcc doesn't publish or adheres to a tiered platform list, but if it was using Rustc's definition it would be at most tier 2 (because tier 1 distributes official binaries, and prevents any tier1-breaking changes from being merged).
If I'm using a device on one of the lower tiers, it's fair to assume that the C compiler for it has been exercised quite a lot, much more than the shiny new rust compiler that I'm introducing that I have no reason to think anybody else has ever used on this platform.
Why would you think that nobody has ever used Rust there ? Somebody has obviously put in the work to support that platform, rustc doesn't just blindly inherits the list of target triples from llvm.
While it's safe to assume that C gets a decent amount of use on every platform, you can't expect all platforms to be as well-supported as the major ones. Undoubtedly, some of those platforms would be listed as low-tier if the C compilers cared to maintain a platform tier list. But a platform being low-tier doesn't mean you shouldn't use that compiler there.
As for trusting Rust or C on niche platforms, C is so full of UB, platform-specific choices, and vendor extensions, that it's hard to ever fully know how well this or that project will work. Rust is much less surprising, if it works at all I expect it to fully work. I'd definitely pick Rust on niche platforms if I have the choice.
There actually isn't that much work to adding basic support for a new platform target for Rust. You're moreso banking on LLVM's ability to target it, which, given clang gives you that C compiler maturity you're after.
> Replacing parts of curl with Rust will not be possible.
It's not just possible, it's been done. You can compile curl with rustls, you could for a time compile it with quiche, and work is ongoing to compile it with hyper. Curl is remarkably modular, none of those are mandatory.
> And Rust supports a tiny subset of possible C targets.
Gross overstatement. Rust supports the vast majority of devices that people buy today. Even if you ignore platform popularity and just count platforms supported by gcc vs rustc/llvm, there's only a handful missing from the later. And if you're talking about vendor-specific compilers, a lot of them don't support modern C or C++ either.
I know almost nothing about the Rust ecosystem but am interested. What Rust packages could completely replace Curl? The top result on Google suggested hyper and reqwest.
You'd need a few different ones, just like curl itself uses a lot of 3rd-party libraries to provide its full feature set.
Some likely first choices would be hyper (http client/server), rustls (encryption), tokio (async scheduling). The Rust ecosystem is quite rich in protocols and codecs, it shouldn't be too hard to find most (all ?) of the crates you need, but there's still work needed to bring them together into one curl-like tool.
Note that Rust crates tend to be more focused than what you're used to in C, made to be composed together instead of used as a one-stop-lib. So your dependency tree would look much bigger than curl's.
Curl supports a lot of protocols, including surprising ones like LDAP, SMTP and POP3, so there is no exact curl replacement anywhere, but Rust already has libraries for every protocol that Curl supports.
Hyper is a pretty robust HTTP toolkit, and reqwest is a higher-level library on top of it.
You need to have someone, or a group of people, willing to write the code to implement support for modern tooling on their platform. Until then, old harder-to-secure codebases is what these platforms have.
I know reversing the burden of implementation seems flippant, but it's pragmatic. At some stage, it's less community-wide work to support Rust on a new platform than to spend extra time maintaining/securing dozens of C codebases. Curl may not be making its Rust components mandatory anytime soon, but other projects like python crypto already have, to say nothing of projects written in Rust to begin with.
rustc_codegen_gcc is pretty close to ready, let's focus on getting it out of the door, and more target triples supported by rustc and llvm.
GPL doesn't force upstreaming, just making the sources available. Plenty of small vendors are not upstreaming their gcc patches. It's more a question of man-hours than of license.
A Go version wouldn't improve anything upon the Rust version either. At this scale, Go's simplicity would be a hindrance more than a help, development velocity would suffer compared to Rust. Integration would only be possible in the Go ecosystem, whereas Rust can expose a C API so that Arti can be used (eventually) as the engine for implementations in other languages (Go, Python, JS, etc). Multithreading and overall performance can be better optimized in Rust.
Tor is critical security software with a lot of implementation gotchas. Just like you shouldn't write your own crypto, you shouldn't write your own Tor. Arti is developed by contributors of the original C Tor, I wouldn't go near a Js/Go/whatever implementation from a team with less credentials.
So ? The fact that rustc compiler uses a component written in C++ doesn't mean that even pure Rust projects have a C++ dependency. Follow any language's bootstrap chain and you'll find C somewhere (or a bootstrapping purists telling you that didn't properly bootstrap the thing), making the "some of the FOOLANG compiler is written in BARLANG" argument pointless.
You don't need a C or C++ compiler (not even Clang) to compile Arti. The rustc packages typically use a vendored version of LLVM.
