I'm mostly interested in being able to interact with the vfs and build a 9p rust client (in addition to the current v9fs) to support my 9p server [0]. Does anyone know what's the current state / what is the current timeline for something like this to be feasible? [0] https://github.com/Barre/ZeroFS
Rust in the kernel is no longer experimental
591–600 of 853 posts
Re: Rust in the kernel is no longer experimental
#592Earlier quoted context omitted.
I am missing some context, did not follow the Linux/Rust drama. which guy?
linus torvalds
If he didn't want Rust in the kernel, he would have said it, and there would have been no Rust in the kernel. It is also the reason why there is no C++ in the kernel, Linus doesn't like C++. It is that simple.
And I respect that, Linux is hugely successful under Linus direction, so I trust his decisions, whatever opinion I have about them.
Re: Rust in the kernel is no longer experimental
#593Earlier quoted context omitted.
I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write. Mostly Rust has been used for drivers so far. Here's the first Rust driver I found: https://github.com/torvalds/linux/blob/2137cb863b80187103151... It has one trivial use of `unsafe` -…
Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.
Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.
Re: Rust in the kernel is no longer experimental
#594Earlier quoted context omitted.
Rightfully so, its probably the place where you'll het most ROI
I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`. In my mind, the reasoning for rust in this situation seems flawed.
You still get the safety guarantees of Rust in unsafe code like bounds checking and lifetimes.
Re: Rust in the kernel is no longer experimental
#595Earlier quoted context omitted.
All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?
Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer. The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processe…
Re: Rust in the kernel is no longer experimental
#596Earlier quoted context omitted.
Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work acros…
Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
Re: Rust in the kernel is no longer experimental
#597Earlier quoted context omitted.
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…
> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp. Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?
Re: Rust in the kernel is no longer experimental
#598Earlier quoted context omitted.
Does this image count as significant tribalism in parts of the Rust community? https://github.com/microsoft/typescript-go/discussions/411#d... Taken from the above Github discussion regarding Go and Typescript. https://imgur.com/a/efdIuWb
How is the one comment from a GH account with 18 followers, no contribution to the Rust project (or any Rust based project at all) and mostly contributions to javascript projects in any way representative of the Rust community? Especially taken out of context - in context it seem like a failed(?) attempt at humor or sarcasm. Do I treat your post from an obvious throwaway account created 13 minutes ago as somehow repr…
For all we know it could be the same person behind both the GitHub post and the Hacker News throwaway you're speaking to.
Re: Rust in the kernel is no longer experimental
#599Earlier quoted context omitted.
I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…
> which has all of the rust safety guarantees and then some That's not really true. Data races are possible in Java.
Re: Rust in the kernel is no longer experimental
#600Earlier quoted context omitted.
> supports 14 of the kernel's 20-ish architectures That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
They probably get a few for "free" from LLVM supporting them