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

51–60 of 184 posts

Re: Rust in QEMU Roadmap

#51

Post by School-Cotton »

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…

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.

Re: Rust in QEMU Roadmap

#52

Post by tangent128 »

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 that the build can be conducted offline entirely from source packages.)

Re: Rust in QEMU Roadmap

#53

Post by jdefr89 »

School-Cotton wrote: post #51
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…

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 bet that it would take way way longer to get off the ground. That being said, using an LLM might help with that but then you would still have code people don't understand and that becomes technical debt... Maybe I am just old and grumpy.. I am learning Rust myself and I just don't understand why it's being pushed so hard. I think Zig should be pushed for systems programming if anything..

Re: Rust in QEMU Roadmap

#54

Post by kbolino »

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.

You're definitely not going to be linking to libc in a no_std environment, which is going to cover much (though not all) of embedded development. That will also remove some of the most bloated library dependencies from even being available to you in the first place, and of the rest, it will debloat a lot of them.

Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).

Re: Rust in QEMU Roadmap

#55

Post by o11c »

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.

There are probably other ways, but the way that seems most "obvious" to me is to define the base via union of all bases in the chain, rather than only the immediate base class. So:

  /*
  class Foo {int f;};
  class Bar extends Foo {int b;};
  class Qux extends Bar {int q;};
  class Leaf extends Qux {int l;};
  */
  struct Foo { int f; };
  struct Bar { union { struct Foo base, base_Foo}; int b; };
  struct Qux { union { struct Bar base, base_Bar; struct Foo base_Foo; }; int q; };
  struct Leaf { struct Qux base; int l; }
Then your "compile-time-safe-cast to base class" macro just checks 3 things in order:

  1. check if we're already the right class.
  2. check if `base` is the right class.
  3. unconditionally try to use the appropriately-named `base_Foo` member as calculated from the type.
(runtime-safe-checked downcasts just have to check that the reverse is possible)

Re: Rust in QEMU Roadmap

#56

Post by duped »

galangalalgol wrote: post #27
ThePhysicist wrote: post #25

Earlier quoted context omitted.

I mean it has polymorphism via v-tables and composition via traits, that's enough object-orientation for me. Inheritance is a core principle of OOP but in practice most C++ class hierarchies are relatively flat (there are exceptions like Qt, which I think uses inheritance in a good way), in practice most of that can be mimicked with embedding and composition well enough to work. Not sure if you want to call that obje…

The one lagging thing that isn't easy with rust's generics is expressions, and that looks to be getting kicked down the road indefinitely. You can't have Foo * Foo -> Foo or similar. That is a useful thing for statically sized math libraries and for performance oriented metaprogramming. The latter can be clumsily handled with macros, but not the former. It is also blocking portable simd from stabilizing, apparently n…

> 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!()
        }
    }

Re: Rust in QEMU Roadmap

#57

Post by hmry »

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…

> Golang has even better memory safety guarantees than Rust

I don't think that's true at all. For one, Go has data races, which lead to undefined behavior and memory corruption. For example, appending to the same slice from multiple threads will corrupt its metadata and can lead to out-of-bounds reads and writes.

Re: Rust in QEMU Roadmap

#58

Post by Novosell »

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…

The US government, Linux, Google, Mozilla and many more see value in memory safe languages, yet I see so many people, like you, saying "No, they're all wrong. Get good.". I just don't get it.

What insights do you have that makes you more qualified than all these organizations combined? What are they all missing?

Re: Rust in QEMU Roadmap

#59

Post by nindalf »

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…

> 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.

Re: Rust in QEMU Roadmap

#60

Post by dralley »

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.

All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.
Post reply on HN