I don’t know, but I also don’t know how much you think is “enough” to deal with project cultural issues. It sounds like it must be quite a bit?

See also Asahi Lina’s thread on this, which explicitly says that Rust is one reason why their drivers cause fewer kernel panics than others: https://vt.social/@lina/113045456734886438

Isn’t your objection there basically “LF doesn’t pay enough for people to put up with negative social dynamics”? In which case, wouldn’t paying more help a lot?

I asked, and it’s to replace some of the bits that require Perl: https://hachyderm.io/@notgull/113035157972265244

You can see the full (current) sequence here: https://bootstrapping.miraheze.org/wiki/Live-bootstrap

That’s the mrustc project the author mentions. He wants Rust to be bootstrapped earlier in the process.

Okay. That’s just imposing a different (and at least equally arbitrary, if not moreso) definition of bootstrapping. Why does it matter that the author didn’t explain their “deeper reasoning” for having an interest in bootstrapping, or the Bootstrappable Builds project specifically? If you feel like that project isn’t meeting a sufficient bar for what counts as “bootstrapping”, or that using C as the first high-level language they bootstrap is “tragic”, take it up with that project, I guess.

The author doesn’t explain exactly what their interest in bootstrapping is, but the goal is pretty explicit:

So, for me, it would be really nice if there was a Rust compiler that could be bootstrapped from C. Specifically, a Rust compiler that can be bootstrapped from TinyCC, while assuming that there are no tools on the system yet that could be potentially useful.

There is nothing special about C.

I wish that were true, but isn’t it somewhat wishful thinking? Even an assembly-language Lisp would require an operating system in order to build a functioning compiler, wouldn’t it? And operating system APIs are in C.

Edit: more importantly, as the post explains, the special thing about C is the existence of TinyCC.

Yeah, that part is pretty wild and definitely Microsoft’s fault.

The Crowdstrike problem was in fact a Crowdstrike problem. It affected Linux too, but of course there are vastly fewer users of Crowdstrike on Linux: https://www.google.com/amp/s/www.theregister.com/AMP/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

This is pretty obviously a Microsoft problem.

What were the issues you’ve had with WSL? I’ve been happily using that for a while now.

I agree with everything in the article, which makes it all the more unfortunate that I really detest Go as a language.

(It’s getting better, though.)

The phrasing “available on servers” does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.

Oh, right, yes; of course it statically links the standard library. I was thinking of the fact that the standard lib is precompiled, but yes, it’s statically linked.

There is nothing specific in the rust port that makes fish more available for servers or LTS distros.

Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.

Why do you think most early adopters use Windows exclusively?

How does the const { None } example type-inference work? The size of the option type can’t be known without knowing the type of the Somevariant.

Edit: aha, it doesn’t work as-is. It needs to infer the type of elements of foo from usage. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=05a95c592626b6935ae812527aa6bbc6

Seconded. Wezterm seems to have a similar level of features and customizability as Kitty, but with Lua as its config/extension language. I migrated from Alacritty rather than Kitty, so I don’t know how Kitty’s speed compares, but I haven’t missed Alacritty, which is honestly saying something.

I’m not familiar with pyo3_async, but I don’t think you can force Python asyncio to use the Tokio event loop. This is discussed in the documentation of a different PyO3 async crate, pyo3-asyblncio: https://docs.rs/pyo3-asyncio/latest/pyo3_asyncio/#why-two-event-loops

What custom implementation? The escaping logic?

Edit: to be clear, there is no “custom implementation” of cmd itself, nor is the problem exclusive to Rust. This is a problem with the Windows cmd itself.