I’m not even sure such recognition is a good idea. Civic service is intended to benefit a (local) community, while open-source work has no such implication. Of course a lot of open-source work does have public benefit, but then maybe it’s better performed as public service, through government funding? I’m an open-source maintainer myself, but I don’t think we should be blind to how open-source can very much be used for commercial benefit.

Don’t be so gloomy! You’re an individual number too! 😜

If I’m not mistaken, their inflation and interest rates are already crazy high, nearing 20%. Yes, they can print even more money, but it won’t give them more resources from abroad, and they’re already nearing the point where they might spiral into hyperinflation.

Heh, I agree with everything you said, but I’m afraid such a framework is impossible to create, let alone implement. It’s impossible to foresee the infinite possibilities for people to screw themselves through bad decisions, so all you’d create is a lot of bureaucracy to still end up in the same place.

It’s a gray area, legally. What you say is theoretically correct, but there’s practical issues once you’ve looked at the code that will open you up to legal liability anyway.


For instance, what if you need a utility function during your reimplementation for which there is really only one obvious implementation? You can no longer claim to have come up with it by yourself.


I doubt the FSF would sue over it, but companies are known to avoid the risk.

I agree the Linux kernel is just fine. But that’s only because despite the security risks of C, there’s no viable alternative kernel.

But development doesn’t stand still, so either Linux catches up, or gets replaced when a viable alternative arrives. Thankfully Linus sees the problem, so they’re working to make the kernel viable a while longer, but I also agree with the person you replied to that this work could definitely use a bit more help.

So I do consider myself to be a true full-stack developer, since I do have 5+ years of experience working on each of server-side, CLI, desktop applications, and mobile applications and 10+ years on the web frontend. Then again, I’m 40 and I feel too old to get offended over that shit. I also agree the term “full-stack” is diluted as hell, so I don’t even call myself that anymore.

Now get off my lawn :p

I think I would put the emphasis slightly differently: I don’t feel the confusion is around the word “spawn”, but it spawns futures rather than tasks. For tasks you might indeed expect them to be picked up in the background (which is what work-stealing does), but futures only execute when polled.

Yeah, sorting is definitely a common use case, but note it also didn’t improve every sorting use case. Anyway, even if I’m a bit skeptical I trust the Rust team that they don’t take these decisions lightly.

But the thing that lead to my original question was: if the compiler itself uses the std sorting internally, there’s also additional reason to hope that it might have transitive performance benefits. So even if compiling the Rust compiler with this PR was actually slower, compiling again with the resulting compiler could be faster since the resulting compiler benefits from faster sorting. So yeah, fingers crossed 🤞

Thanks! That’s very much what I was looking for!

Yeah, that's helpful if I would be currently optimizing a hot loop now. But I was really just using it as an example. Also, retain_mut() doesn't compose as well.

I'd much rather write:

let vec_a: Vec<String> = /* ... */;
let vec_b: Vec<String> = vec_a
    .into_iter()
    .filter(some_filter)
    .map(some_map_fn)
    .collect();

Over:

let mut vec_a: Vec<String> = /* ... */;
vec_a.retain_mut(|x| if some_filter(x) {
    *x = some_map_fn(*x); // Yikes, cannot move out of reference.
    true
} else {
    false
});

And it would be nice if that would be optimized the same. After all, the point of Rust's iterators is to provide zero-cost abstractions. In my opinion, functions like retain_mut() represent a leakiness to that abstraction, because the alternative turns out to not be zero cost.

I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.