Rust in QEMU Roadmap • Hacker News Board

Re: Rust in QEMU Roadmap

#171

Post by vlovich123 » Thu, Dec 05, 2024, 8:37 AM UTC

bonzini wrote: post #149

vlovich123 wrote: post #142

Earlier quoted context omitted.

Sure, but then why does the mainline branch need to worry about supporting the rust that’s bundled with the last stable Debian release? By definition that’s not going into a distro (or the distro is building mainline with rusts latest release anyway). Is it a precautionary concern that backporting patches gets more complicated if the vuln is in Rust code? But then again Rust code isn’t even compiled by default so I g…

We already make an exception in that we don't support Debian bullseye (which is supported by the rest of QEMU until the April 2025 release), but not supporting Debian stable at all seemed too much. That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.

I think I'm missing why you need to require using the toolchain bundled with the last stable Debian release vs having devs just rustup the latest version of the toolchain (or via a PPA [1] or however else they want to install it).

The current approach basically guarantees that you're always targeting a ~2-4 year old version of the toolchain and that feels like a particularly weird maintenance burden given how many workarounds you're putting in to do so.

[1] https://launchpad.net/~jonathonf/+archive/ubuntu/rustlang

Re: Rust in QEMU Roadmap

#172

Post by vlovich123 » Thu, Dec 05, 2024, 8:39 AM UTC

School-Cotton wrote: post #165

0x457 wrote: post #83

Earlier quoted context omitted.

> Most toolchains don't have as much churn as Rust. What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code. Now compare rust releases to this: https://gcc.gnu.org/releases.html

> latest rustc always able to compile older rust code. That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.

I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.

Re: Rust in QEMU Roadmap

#173

Post by School-Cotton » Thu, Dec 05, 2024, 10:15 AM UTC

vlovich123 wrote: post #172

School-Cotton wrote: post #165

Earlier quoted context omitted.

> latest rustc always able to compile older rust code. That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.

I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.

It is correct. For example, this code (admittedly a contrived example, just to illustrate the point) compiles in 1.82 but not in 1.83:

  trait OptionExt {
      fn get_or_insert_default();
  }
  
  impl OptionExt for Option {
      fn get_or_insert_default() {}
  }
  
  fn main() {
      Option::::get_or_insert_default();
  }

The reason is that `get_or_insert_default` was added to the stdlib in 1.83, and takes a different number of arguments, so it clashes with the user-defined one here.

Re: Rust in QEMU Roadmap

#174

Post by bonzini » Thu, Dec 05, 2024, 2:50 PM UTC

crabbone wrote: post #161

quotemstr wrote: post #121

Earlier quoted context omitted.

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 ex…

I don't know... I basically already answered your question: C++ has way too many things to remove. People working on projects like QEMU don't want exceptions, smart pointers, classes, virtual methods, templates, lambas etc. So, it's more effort to remove all of that / make sure your code doesn't accidentally use any of that. C is simpler because you don't need to remove any of that stuff, because it's not there to be…

Well, smart pointers and (sort of) templates and lambdas are in Rust. I definitely want smart pointers.

Re: Rust in QEMU Roadmap

#175

Post by bonzini » Thu, Dec 05, 2024, 2:52 PM UTC

vlovich123 wrote: post #171

bonzini wrote: post #149

Earlier quoted context omitted.

We already make an exception in that we don't support Debian bullseye (which is supported by the rest of QEMU until the April 2025 release), but not supporting Debian stable at all seemed too much. That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.

I think I'm missing why you need to require using the toolchain bundled with the last stable Debian release vs having devs just rustup the latest version of the toolchain (or via a PPA [1] or however else they want to install it). The current approach basically guarantees that you're always targeting a ~2-4 year old version of the toolchain and that feels like a particularly weird maintenance burden given how many wo…

Because it's not about devs, it's about distro packagers. They are an extremely important audience for QEMU. As pm215 said above, we don't want to make their lives unnecessarily harder. For example Debian has the backports repository, and CentOS Stream has QEMU and Rust updates done by different teams.

Anyhow starting April (August release) we will be able to target 1.75.0 while being consistent with QEMU's (C-targeted) distro support policies, which is not that bad. Maybe newer than that depending on what Ubuntu 22.04 does between now and August.

Re: Rust in QEMU Roadmap

#176

Post by crabbone » Thu, Dec 05, 2024, 3:41 PM UTC

bonzini wrote: post #174

crabbone wrote: post #161

Earlier quoted context omitted.

I don't know... I basically already answered your question: C++ has way too many things to remove. People working on projects like QEMU don't want exceptions, smart pointers, classes, virtual methods, templates, lambas etc. So, it's more effort to remove all of that / make sure your code doesn't accidentally use any of that. C is simpler because you don't need to remove any of that stuff, because it's not there to be…

Well, smart pointers and (sort of) templates and lambdas are in Rust. I definitely want smart pointers.

Not when you need your own allocator. Anything that tries to manage memory w/o you knowing about it will be working against you.

Re: Rust in QEMU Roadmap

#177

Post by bonzini » Thu, Dec 05, 2024, 9:53 PM UTC

crabbone wrote: post #176

bonzini wrote: post #174

Earlier quoted context omitted.

Well, smart pointers and (sort of) templates and lambdas are in Rust. I definitely want smart pointers.

Not when you need your own allocator. Anything that tries to manage memory w/o you knowing about it will be working against you.

Smart pointers are not really about managing memory, they're about managing lifetimes. Even things like the Rust RefCell are smart pointers.

Re: Rust in QEMU Roadmap

#178

Post by crabbone » Fri, Dec 06, 2024, 10:44 AM UTC

bonzini wrote: post #177

crabbone wrote: post #176

Earlier quoted context omitted.

Not when you need your own allocator. Anything that tries to manage memory w/o you knowing about it will be working against you.

Smart pointers are not really about managing memory, they're about managing lifetimes. Even things like the Rust RefCell are smart pointers.

Rust lifetimes is a mechanism to manage memory.

Re: Rust in QEMU Roadmap

#179

Post by 0x457 » Fri, Dec 06, 2024, 7:20 PM UTC

vlovich123 wrote: post #134

0x457 wrote: post #83

Earlier quoted context omitted.

> Most toolchains don't have as much churn as Rust. What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code. Now compare rust releases to this: https://gcc.gnu.org/releases.html

Rust’s release cadence is 6 weeks not 6 months.

My bad, I thought it was 6 months. Okay, a bit too often, but no reason why debian folk can't update it more often than it is now.

Re: Rust in QEMU Roadmap

#180

Post by uecker » Sun, Dec 08, 2024, 2:10 PM UTC

School-Cotton wrote: post #166

uecker wrote: post #131

Earlier quoted context omitted.

I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.

Why is downloading a shell script from a website and running it any less safe than downloading a package from a distro repository and running it? The owners of rustup.rs are just as unlikely to be malicious as the people who package things for Debian.

Adding a package repository is a very conscious choice that also requires a password. Cut & pasting a line of code from we website is not. This is why a lot of time and effort was spend in the past educating users not to run random code from the internet. That is may be safe in this particular specific case does not change the fact that this generally undermines the message that one should not cut&paste arbitrary code from a website into a terminal.