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

91–100 of 184 posts

Re: Rust in QEMU Roadmap

#91

Post by jdefr89 »

jodrellblank wrote: post #70
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…

> " 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 pla…

You’re right that is an opinion. I said that to emphasize the opinion…

Re: Rust in QEMU Roadmap

#92

Post by kstrauser »

bonzini wrote: post #69
nindalf wrote: post #59

Earlier quoted context omitted.

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

That's been my experience. The troubles I've had with Rust were when I was trying to do things the way I would've in C, and either rustc or cargo clippy told me that my idea is bad and there's a better way. I feel like I've learned a lot about better coding in general from it.

Re: Rust in QEMU Roadmap

#93

Post by dralley »

jdefr89 wrote: post #88
dralley wrote: post #60

Earlier quoted context omitted.

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.

Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.

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 microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.

Re: Rust in QEMU Roadmap

#94

Post by quotemstr »

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…

Instantiation time errors unlock so much metaprogramming potential that Rust is going to be forced to allow them sooner or later.

Re: Rust in QEMU Roadmap

#95

Post by quotemstr »

crabbone wrote: post #34
tejohnso wrote: post #24

Earlier quoted context omitted.

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?

I worked for a large infra project that was mostly written in C with the kind of trickery that is being here ascribed to QEMU code (I trust the parent, but I haven't seen the code myself). It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with…

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

Re: Rust in QEMU Roadmap

#96

Post by quotemstr »

sureglymop wrote: post #40
jdefr89 wrote: post #29

[flagged]

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…

C++'s metaprogramming is still better. Rust needs specialization, const expressions, and a bunch of other things before it can be a full replacement for C++.

Re: Rust in QEMU Roadmap

#97

Post by bluGill »

sureglymop wrote: post #40
jdefr89 wrote: post #29

[flagged]

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…

> why should I start a new project

You should not. Simple as that. Odds are very good there already is a project that does what you want and you should join or buy that. If you start a new project you have a lot of effort to be just as good as the previous one, and those projects are not standing still.

Okay, maybe it makes sense to start a new game. However you should use an existing game engine not build your own. A few other things like that exist.

Re: Rust in QEMU Roadmap

#98

Post by melon_tusk »

kouteiheika wrote: post #71
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…

> 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, not execution time).

Re: Rust in QEMU Roadmap

#99

Post by bluGill »

jodrellblank wrote: post #64
jdefr89 wrote: post #42

Earlier quoted context omitted.

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…

You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.

Re: Rust in QEMU Roadmap

#100

Post by Daishiman »

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, they could have just written secure C.. That is just my personal opinion.

Empirical evidence from the largest software firms in the world who do research on objective metrics on software defects show that there's no such thing as secure C and that Rust is slightly more productive.

Post reply on HN