Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in QEMU Roadmap

lore.kernel.org

Post reply on HN
Print view View original

61–70 of 184 posts

Re: Rust in QEMU Roadmap

#61

Post by bonzini »

o11c wrote: post #55
bonzini wrote: post #2

Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit on the safe abstractions that are mentioned in the roadmap).

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. Ther…

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." :D

Though I admit that Rust also has to include the full list of base classes (https://github.com/rust-lang/rfcs/pull/1268 would fix it).

Re: Rust in QEMU Roadmap

#62

Post by School-Cotton »

jdefr89 wrote: post #53
School-Cotton wrote: post #51

Earlier quoted context omitted.

Go just feels a lot less productive to me than Rust. It feels very low level and boilerplate-intensive like C even though it has a garbage collector.

A team can learn and start using Golang in a week. That is in fact what is powering a lot of companies right now. Golang has even better memory safety guarantees than Rust and you don't really need to worry about memory management at all... Furthermore its compiled statically and more suitable for distribution and horizontal scaling. I am not sure how quickly a team can become productive in Rust but I am willing to b…

> A team can learn and start using Golang in a week

True, but why should we be optimizing for the first week experience? Your career lasts 40 years.

> Golang has even better memory safety guarantees than Rust

That is not true. What specific example did you have in mind? As an example of something Rust can enforce that Go can’t is not mutating something that’s shared between threads without acquiring the proper lock.

> Furthermore its compiled statically and more suitable for distribution and horizontal scaling.

Rust can be statically linked just like Go can. Not sure what else you think makes it less suitable for distribution and horizontal scaling. There are certainly lots of companies distributing Rust programs and horizontally scaling them so this seems empirically false.

> I am learning Rust myself and I just don’t understand why it’s being pushed so hard.

Because it has a lot of nice features that make a lot of people like it - memory safety without GC, prevention of data races, algebraic data types, etc. No other mainstream compiled languages has this set of features. There’s no conspiracy to “push” Rust. The push is organic. People just like it.

Re: Rust in QEMU Roadmap

#63

Post by vlovich123 »

tangent128 wrote: post #52
vlovich123 wrote: post #35

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down. So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories. (Not just rustup- Debian requires repackaging Cargo dependencies so tha…

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support.

This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo that makes the latest tool chain available on older Debian platforms.

As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. The current policy Debian is holding is really difficult to work with and causes downstream projects to do all sorts of workarounds to make Debian builds work (not just for Rust by the way - this applies to C++ as well). And it’s not like this is something it’s unfamiliar with - you can install multiple JVM versions in parallel and choose a different default.

Re: Rust in QEMU Roadmap

#64

Post by jodrellblank »

jdefr89 wrote: post #42
sureglymop wrote: post #40

Earlier quoted context omitted.

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In m…

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

> "Sure just wrap everything in "Unsafe"... So what is the point?"

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."

Re: Rust in QEMU Roadmap

#65

Post by jodrellblank »

jdefr89 wrote: post #29

[flagged]

> "The current trend of rewriting everything in Rust is out of control and misguided... EDIT: lcamtuf does a great job explaining my perspective on Rust push https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-... "

The current trend is people rewriting Unix command line utilities in Rust, as a hobby. Nobody is rewriting Adobe PhotoShop or Oracle in Rust.

Can you name some projects which you class as "out of control"?

[I don't use Rust, so this isn't "you should RiiR". Adobe isn't rewriting photoshop in Rust because of some Twitter/tech news hype. And if Adobe is rewriting Photoshop in Rust over the coming decades because of government guidance, is that really "out of control"?]

Re: Rust in QEMU Roadmap

#66

Post by bonzini »

JoshTriplett wrote: post #45
bonzini wrote: post #13

Earlier quoted context omitted.

Right now the only language-level thing I would like is const operator overloading. Even supporting MSRV as old as 1.63 was not a big deal, the worst thing was dependencies using let...else which we will vendor and patch. Pin is what it is, but it is mostly okay since I haven't needed projection so far. Initialization using Linux's "impl PinInit " approach seems to be working very well in my early experiments, I cont…

> Right now the only language-level thing I would like is const operator overloading. As far as I know, const traits are still on track. > easier passing of closures from Rust to C As in, turning a Rust closure into a C function-pointer-plus-context-parameter? > The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standa…

> As far as I know, const traits are still on track.

Yes they are. My use case is something like the bitflags crate, there are lots of bit flags in emulated devices of course. In the meanwhile I guess it would be possible to use macros to turn something like "bit_const!(Type:A|B)" to "Type(A.0|B.0)" or something like that.

> As in, turning a Rust closure into a C function-pointer-plus-context-parameter?

Yes, more in general everything related to callbacks is doable but very verbose. We might do (procedural?) macro magic later on to avoid the verbosity but for now I prefer to stick to pure Rust until there's an idea of which patterns recur.

Let me know by email about any occasions to present what I have.

Re: Rust in QEMU Roadmap

#67

Post by winocm »

Neywiny wrote: post #21

I've said this before on here and I'll say it again. The QEMU code base is a nightmare. The amount of fake C++ is mind numbing. Every time I come across a variable or strict declaration or method with the word "class" in it, I'm reminded of how much easier the whole thing would've been with C++. You can't even compile C++ into QEMU because of how the headers use keywords. That's not even touching their macro abuse te…

Yeah, even integrating any C++ into it and calling any QEMU functions via extern "C" declarations when including the headers cause many issues because many variables are named "new" or have type cast issues.

It's a full time job on its own to fix all of the compilation errors. Could probably fix it with coccinelle scripts to make some parts easier, but still, validating the codebase with different compilers to make sure there's no resulting subtle breakage either still requires a lot of effort.

Re: Rust in QEMU Roadmap

#68

Post by ronsor »

vlovich123 wrote: post #63
tangent128 wrote: post #52

Earlier quoted context omitted.

Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down. So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories. (Not just rustup- Debian requires repackaging Cargo dependencies so tha…

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo tha…

> As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed.

Most toolchains don't have as much churn as Rust.

Re: Rust in QEMU Roadmap

#69

Post by bonzini »

nindalf wrote: post #59
jdefr89 wrote: post #44

Earlier quoted context omitted.

What are the other advantages exactly besides tool chain? A lot of people using Rust where the could have just used Go or another language that is memory safe and actually productive. Maybe I am just being a hater because I grew up on C/C++ but I know for a fact "Rustaceans" are getting out of control. Approaching zealot territory for sure. The time people spend fighting the Rust compiler for a project, they could ha…

> The time people spend fighting the Rust compiler for a project To be clear, this isn't time you've spent yourself. You're saying this based on hearsay that other people are struggling with this. Not that I'd convince you, but this is mostly an issue that beginners face. Folks who can get past that hump enjoy a plateau of productivity.

And really it's not so much fighting the compiler as it's understanding your code better—in ways that help you even when writing C.

The times that you do fight the compiler it will suggest the right thing (add clone, add &, add *, import a type or trait).

Re: Rust in QEMU Roadmap

#70

Post by jodrellblank »

jdefr89 wrote: post #44
School-Cotton wrote: post #31

Earlier quoted context omitted.

The fact that rust makes it harder to write memory corruption bugs is only one of its many advantages. It’s genuinely a lot nicer and easier to use than comparable languages like C++, and I’d prefer it to that even if I didn’t care about memory corruption at all. Also, what’s wrong with the syntax? I hear a lot that people find the syntax ugly but I never understood what’s so fundamentally different about it compared…

What are the other advantages exactly besides tool chain? A lot of people using Rust where the could have just used Go or another language that is memory safe and actually productive. Maybe I am just being a hater because I grew up on C/C++ but I know for a fact "Rustaceans" are getting out of control. Approaching zealot territory for sure. The time people spend fighting the Rust compiler for a project, they could ha…

> "I know for a fact "Rustaceans" are getting out of control"

That isn't a fact, that's an opinion. A pearl-clutching, panicky, fact-free opinion framed in terms of "control" which raises questions about who you think should be "controlling" those uppity people who are doing things you don't like.

Seriously - an explosion can be out of control, but other people aren't supposed to be in your control in the first place, right? That's basic freedoms and so on. How is your position any different to any other entrenched social / power structure attempting to control people who want things to change?

Post reply on HN