moltonel3x

According to SlashData "size of programming language communities, Q1 2025":

   28.0M JS+TS
   ...
   5.6M Swift
   5.1M Rust
   5.0M Go

They have measured Rust growing faster than Go over the years, with the overtake finally happening in Q1 this year.

There aren't a lot of reports presenting absolute numbers and not biased toward a handful of platforms or ecosystems. If you know of other good free ones, feel free to share.

https://research.slashdata.co/reports/6814fddffed4a97023eab0...

That's very subjective, I find the Google style barely usable compared to OSM carto. No experience with Apple.

Rust does support adding deps using git urls, alternate repositories, filesystem paths, and even multiple sources for one dep.

https://doc.rust-lang.org/cargo/reference/specifying-depende...

D, Ada, and Modula don't have enough traction.

Go's runtime can be a showstopper, especially for multi-language projects.

C++ may be better than C, but many people feel that Rust is even better.

Rust is already available in almost all scenarios, there's no need to wait for it.

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.

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.

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).

> 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.

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.

Loongarch is at tier3 as well: https://doc.rust-lang.org/nightly/rustc/platform-support/loo...

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.

On single C file, 159 lines compared to 83000 lines of Rust. It's used to generate a cert for unittests, not sure why that's not done in Rust.

Having C or C++ somewhere in the lower levels of your stack doesn't make them the primary language for your domain. Other wise CPU microcode would be the primary language of every domain.

Yes, public github repos, stackoverflow survey respondents, devjobscanner offers, google searches, etc are all skewed in some way.

It's very hard to qualify the effect of those biases though: for example how does the public/private repo ratio differ between languages ? Good luck giving a trustworthy answer to that. Apart from looking at lots of different source kinds, one thing that's fairly trustworthy is the trend of a specific language in a specific source.

On that topic, looking at the "SO questions" metric of the first link, C and C++ both have a strange regular spike in the last quarter of each year. I attribute that to new CS students flocking to SO at the beginning of their term. Another fun trend to look at is the hourly google searches over a week: the weekdays / workhours spike is much more pronounced for some languages than others.

Different metrics tell a different story. For example GitHub pull requests [1] are C++: 2.60%, Rust: 2.09%, C: 1.43%, with a clear trend showing Rust ahead of C++ next year. Or you could look at the Stackoverflow survey of languages used among professionals [2], which gives C++: 20.17%, C: 16.7%, Rust: 8.8%, with rust gaining 1-2% each year.

There's no best metric, they're all biased, you need to consider a few different ones. Otherwise you won't notice when you've stumbled upon one with with an extreme view.

Combining C and C++ in language stats is debatable, they should IMHO be measured separately. When grouped as a language category, "C/C++/Rust" is slowly becoming more common.

1: https://tjpalmer.github.io/languish/#y=pulls&names=c%2B%2B%2...

2: https://survey.stackoverflow.co/2022/#most-popular-technolog...

SWC (by the same author as this tentative tsc port) is a part of more and more people's typescript toolchain, and is written in Rust. Having all your ecosystem in a single language feels nice, but pragmatically different tools might be better in different languages.

> Afaict, none of them requires multiple mutable references to the same objects

They ask to store objects ("turtles") into a single Vec. Two turtles from that Vec can breed to create a child turtle stored in that same vec. Parents must retain a reference (a real ref, not an index or other workaround) to their children, meaning that children have multiple refs. Children can become parents themselves, so all the turtles are mutable.

There you have it: multiple mutable references to the same object. With proper Rust you'll need some kind of RefCell to implement this (convoluted) design. The runtime check will ensure a runtime panic if you try to make the same object mutable via different RefCells (trying to breed a turle with itself). With BronzeGc the compiler will believe that they are different objects, and UB-optimize accordingly.

There are a lot of Rust GC approaches here, makes me wonder why the study author didn't use one (or more) of the existing sound GCs. Remove a glaring flaw of the study, and spend less time writing throw-away code.

Sorry, bad mischaracterisation on my part, annoyingly it's too late to edit my post.

Looking at the Ada docs again, it considers manual deallocation an unsafe operation and suggests avoiding it altogether (IIUC, by restricting yourself to the stack or by leaking to the heap). That seems like a huge restriction, making the "Ada is safer than Rust" claims rather academic.

He (and other prominent kernel developers) has manifested his interest many times, but is taking a strict "wait and see" approach (as you would expect from any big project manager). Whether it happens or not, Rust has gotten closer to inclusion in Linux than any other language.

The coreutils rewrite is essentially a hobby project, which nobody is going to switch to until it can boast 100% compatibility. So of course it's slow coming, it's not a fair comparison. There's also the issue that writing a drop-in replacement is harder and less attractive than making something better (see ripgrep and other coreutils alternatives).

Userland is worth fighting for too. https://imgs.xkcd.com/comics/authorization.png

But as bawolff said, the main issue is moving towards safer tech. If Ada had good enough momentum, we'd be discussing Ada in the kernel instead. C++ has been rejected from Linux, leaving Rust as the only kernel-capable language with enough momentum, so Rust it is.

A lot of those guarantees are only available in the alloc-free subset of Ada, which make them much less attractive. The devil is in the details, making Ada guarantees not always better than Rust ones.

D and Ada both use a GC in many contexts, and are not half as interesting in their GC-less contexts. They both initially only had a proprietary compiler, which durably harmed adoption. They both seem to cater to fewer domains than C/C++/Rust. Today Ada is only used in high-stakes industry, and D doesn't seem to have any claim to fame. It's a pity that neither succeeded in their time, but there's no good reason to use either of them today.

Zig is very promissing, but is just too new.

You failed to mention C++. It's well loved (and hated), has many pros and cons compared to C, and is used for kernel development (just not Linux).

It's silly to think that the only explanation for Rust success is community lobbying. Rust has many concrete advantages, like being safer than C/C++/D/Zig, being fully GC-free and suitable for kernel and embedded development, having actually gained significant traction, having great tooling/docs/ecosystem... And generally being a language that people enjoy. Rust isn't the end-game of kernel programming, but it isn't just "yet another better C".

Rust isn't only nibbling at the C/C++ niches: thanks to its correctness and productivity aspects it also attracts people coming for example from Go/Python/Javascript.

In some way, you could say that Zig is pulling system programmers towards high-level programming, whereas Rust is pulling high-level programmers towards system programming. That's not a watertight comparison but I think it's an insightful one.

This points to the larger perception issue that "anybody who advocates for Rust is part of the Rust community and/or knows Rust well". But there are many Rust evangelists who obviously don't know much about Rust (this is not Rust-specific, it's a common issue in tech). This kind of "positive FUD" is ultimately harmful, as outsiders understandably get tired of the hype and start ignoring any pro-Rust argument, good or bad.

In my experience, the community of actual Rust users is much more level-headed. While most do love the language and the "this aspect of Rust is irrefutably better than the equivalent in $OTHERLANG" opinion occasionally pops up, the community seems pragmatic and well aware of Rust's cons. Case in point: the "should I use Rust" questions on the rust subreddit don't get dogmatic answers, and often result in "Rust isn't ideal for your use-case" advice.

Adding Rust complicates things, but Rust makes writing correct code easier, which is no small feat in the kernel world. The added complexity may be big, but it's a one-time cost compared to the stream of Rust code that one can hope for.

Rust is known to be hard to learn (YMMV), but C is even harder. If things go according to plan, someday for some use-cases you'll be able to contribute kernel code in pure safe Rust without having to learn C. In the meantime, adding Rust doesn't seem to be such a big ask when you consider what the kernel already has beside C: Assembler, the "C preprocessor (yes, it's actually a different language independent from C, and some kernel macros are really complicated), the BPF an io_uring APIs (essentially their own DSL), and a myriad of other inner-platform curiosities you might need to deal with depending on the kind of kernel work you do.

Concerning Zig, the cons may be smaller then Rust, but so are the pros. IMHO it's not worth it in the current context (I like Zig but it seems "too little, too late" to me). But there's no telling until somebody puts in the work for a "$OTHER_LANGUAGE in the kernel" RFC like is currently happening for Rust.

"opt.ok_or(err)?" is a pretty neat way of returning early with the error "err" if opt is empty. This is pretty idiomatic Rust you should get familiar with before comparing the readability with a language you know better.

I see a few places where Rust is definitely more readable, for example

    for offset in 0..PL061_GPIO_NR {
       if inner.csave_regs.gpio_dir & bit(offset) != 0 {

vs

    for (offset = 0; offset < PL061_GPIO_NR; offset++) {
       if (pl061->csave_regs.gpio_dir & (BIT(offset)))

OTOH, the next line is a real mouthful in Rust compared to C:

    if let Ok(v) = <Self as gpio::Chip>::get(data, offset.into()) {
      inner.csave_regs.gpio_data |= (v as u8) << offset;
    }

vs

    pl061->csave_regs.gpio_data |=
 pl061_get_value(&pl061->gc, offset) << offset;

 * "<Self as gpio::Chip>::" is the price Rust pays for having multiple possible "get()" for the same data, but it could be hidden away in a wrapper if needed.
 * ".into()" might be due to a young not-yet-ergonomic API
 * The last difference comes from the API difference where Rust's get() actually tells you if it could get that integer instead of (presumably) returning the integer 0. The C API is arguably a footgun, justifying Rust's slightly wordier syntax.

For a more subjective example, I find "pl061.base.readb(GPIODIR)" more readable than "readb(pl061->base + GPIODIR)". Bonus: the offset argument can be enum-typed, avoiding the footgun of reading from an invalid offset.

Going back to the probe functions, I find them hard to compare as I do not know how the hardware works. If that "device::Data::new()" is equivalent to the many lines of init in the C version, it looks less footguny. In the same vein, "Ref::try_new_and_init()" and "data.registrations()" look like they are giving the developer more guarantees.

There's a trend there : some Rust APIs may be wordier but still easier to read/review, because they uphold more invariants, which reduces the reviewer's cognitive load.

Concerning the ack() functions I'm not sure. It seems that Rust is checking that it has proper access to the data ressource while C doesn't. I would turn the question around : How are you sure that "gpiochip_get_data(irq_data_get_irq_chip_data(...))" never fails and can be safely dereferrenced ?