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

121–130 of 184 posts

Re: Rust in QEMU Roadmap

#121

Post by quotemstr »

crabbone wrote: post #120
quotemstr wrote: post #95

Earlier quoted context omitted.

You can define your own "language", the way you describe it, in C++ more easily than you can in C. C++ gives you more powerful and expressive tools for doing so. A program is not improved by foregoing these tools. There's nothing in C++ forcing you to do anything that makes anything "harder".

I wouldn't be so quick to put "easy" and "C++" in the same sentence... Also, C and C++ language tools suck, when it comes to making a language compared to anything in Lisp family, for example, or any language that has Lisp-like macros. C wasn't chosen for it's ability to make other languages. It was an easy target. The benefits are the simpler and more malleable runtime that can be made to do all sorts of weird thing…

Lisp is a non sequitur. C++ can do the same "weird things" C can. There is literally no advantage whatsoever of choosing to wear the C hairshirt instead of using C++. Not a single one.

Sure, Rust is better than C++ in some ways. You can have a legitimate debate about C++ versus Rust. There can be no debate about C versus C++: the latter is better in every single way.

> unnecessary excess of C++.

Is the unnecessary excess of C++ in the room with us right now?

Again, you don't have to use any part of C++ you don't like. A few minor spelling differences aside, it remains a superset of C. Using C++ not C will not hurt you in any project whatsoever.

Re: Rust in QEMU Roadmap

#122

Post by akira2501 »

keybored wrote: post #114
akira2501 wrote: post #18

Earlier quoted context omitted.

> one of the biggest long-standing developers How many developers does the project have? What is your metric for "biggest?" Just total number of contributions? > You're complaining that the developers of QEMU themselves Yep. Do any of them work for any commercial companies? Or are we ignoring that to make an argument of appeals? If they all left would QEMU have zero developers? > because they think it'll work well fo…

What leg do you think you have to stand on when it comes to Rust in Linux? Linus Torvalds is fine with the Kernel experimenting with Rust.

What leg do you think you have to stand on to debate in such a manner? If you want to challenge the ideas, here on _hacker news_, then that would obviously be welcome, if all you want to do is appeal to authority in an effort to declare the conversation as invalid then you've added nothing and behaved disrespectfully.

Should call this site "embarrassed hacker propaganda." At least then you'd "have a leg to stand on." What a gross tactic you've relied on here.

Re: Rust in QEMU Roadmap

#123

Post by jefbyokyie »

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…

C++23 is a godawful mess; especially the functional paradigms (which look beautiful in e.g. OCaml) that got shoehorned kicking and screaming into the morass that C++ had already been.

If you read function specs in the OCaml docs, they're understandable and the syntax is clean; the same concepts bolted onto C++ look like line noise, both in actual syntax and the (allegedy) English-language description on en.cppreference.com.

Reading the C++ standard itself is an exercise in futility, very much unlike the C standard. (Although, latest developments in C land are repulsive too, IMO.)

The C++ committee's tantrums and scandals (physical violence at meetings!) put the worst that has been seen in open-source communities to shame. https://izzys.casa/2024/11/on-safe-cxx/> has been posted to reddit and HN recently.

C++ compilation still takes absolutely forever, and C++ template error messages are as incomprehensible as ever.

One important problem with C++ (repeated ad nauseam, so this is nothing new) is the unforeseen and unintended harmful interactions between such language features that were supposed to be orthogonal. The only remedy for that is to stop adding stuff to the language; but nooo, it just keeps growing.

Another important problem is that, the more the compiler does for you implicitly, the less you see (and the less you can debug) what happens in the code. This is not a problem in OCaml, which is a managed language with a safe runtime, but it's a huge problem in C++, which remains a fundamentally unsafe language. (And yes, once you start extending OCaml with C, i.e., mixing implicit and explicit, OCaml too becomes unsafe, and a lot of head-scratching can occur.) A home-grown object system in C is at least explicit, so it's all there for the developer to read, instrument, step through, and so on.

When your "core guidelines" https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> could fill a book, there's a problem with your language.

(I'm not here to defend QEMU's object model indiscriminately; I'm here to bash C++.)

Re: Rust in QEMU Roadmap

#124

Post by jefbyokyie »

vlovich123 wrote: post #78
pm215 wrote: post #72

Earlier quoted context omitted.

It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we…

To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the…

> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

What Debian has is not a "stranglehold" but an ideology, and Debian continues to matter to (some) upstream projects because lots of users identify with Debian's hyperconservative, noncommercial ideology.

Your complaint is basically, "it's too bad that the userbase not sharing my values is large enough to matter".

Re: Rust in QEMU Roadmap

#125

Post by IshKebab »

masklinn wrote: post #22
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…

> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.

I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively).

I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.

Re: Rust in QEMU Roadmap

#126

Post by IshKebab »

tejohnso wrote: post #24
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…

What are the advantages of trying to use fake c++ instead of actual c++ for their use case? I'm sure there are / were smart people working on the project. Do they keep decision records? Have you had a conversation with the relevant people about it?

The only advantage I know of is that it means you stay within the C ABI. It can simplify linking a little in some cases, or FFI. I guess compilation is faster too.

But yeah broadly speaking it's a terrible idea.

Re: Rust in QEMU Roadmap

#127

Post by yjftsjthsd-h »

vlovich123 wrote: post #78
pm215 wrote: post #72

Earlier quoted context omitted.

It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we…

To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the…

> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

Does Debian have a stranglehold? AFAIK every other distro does the same thing, and all of them for good reasons.

Re: Rust in QEMU Roadmap

#128

Post by steveklabnik »

jdefr89 wrote: post #102
dralley wrote: post #93

Earlier quoted context omitted.

Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontro…

Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.

This is closer to an RTOS, but since we're also talking about embedded, we wrote https://hubris.oxide.computer/ for use in our products.

Kernel is about 3% unsafe code last I checked, which was just a few months ago.

Re: Rust in QEMU Roadmap

#129

Post by steveklabnik »

melon_tusk wrote: post #98
kouteiheika wrote: post #71

Earlier quoted context omitted.

> What are the other advantages exactly besides tool chain? It's a very productive language once you're experienced. I'm one of those people who (initially) didn't care about memory safety at all and just wanted a more productive C++, and for me it delivers on that perfectly. Nowadays I even use Rust for scripting , because with the right libraries it's just as productive for me as Ruby and Python can be while being…

"as productive as Ruby or Python" So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python. I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, n…

I wrote a comment a while back on this topic; someone asked for a comparison between a little Python script and Rust. You can see both versions linked here https://news.ycombinator.com/item?id=40089906

Re: Rust in QEMU Roadmap

#130

Post by [deleted] »

ynik wrote: post #73
duped wrote: post #56

Earlier quoted context omitted.

> You can't have Foo * Foo -> Foo or similar. You can though, unless I totally misunderstand your syntax use std::{marker::PhantomData, ops::{Add, Mul}}; pub struct Foo { _p: PhantomData , } impl Mul > for Foo where N: Add { type Output = Foo >::Output>; fn mul(self, rhs: Foo ) -> Self::Output { todo!() } }

You misunderstood. N, M are supposed to be integers (const generics); in your example code you've made them types. Also, your `type Output = Foo >::Output>;` just means "multiplication has the same return type as addition". But desired is that multiplying a Foo with a Foo results in a Foo . Rust decided that it's important to not have instantiation-time compiler errors, but this makes computation with const generics…

[deleted]
Post reply on HN