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
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.
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.
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 Some
variant.
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
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.
How so? This exploit requires running a shell command in a way that permits an attacker to control the arguments provided. That doesn’t seem like it would be particularly common in build scripts.
That’s fair.
Uh, neither did you? Both explanations mostly just provide links.
Maybe, but the comment I was responding to is not at all clear about what is deprecated and what is no longer an issue. Note, too, that the other top-level comment on the post is from someone who didn’t realize that destructors can be missed.
Well, it’s still true that mem::forget
is safe, and Rust will almost certainly never change that. As noted in the blog post, this makes certain patterns unsound.
Wow, that was not at all clear. I was shocked that 50% of respondants identify as LGBTQ; 7% is a much less surprising figure.
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?