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

161–170 of 184 posts

Re: Rust in QEMU Roadmap

#161

Post by crabbone »

quotemstr wrote: post #121
crabbone wrote: post #120

Earlier quoted context omitted.

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

My argument about Lisp doesn't say that anyone should use Lisp instead, it just points out that people making the choice between C and C++ aren't concerned by how easy it is to build new languages using the language building tools of C or C++ because both are very bad at it. Had the objective of building a new language been the primary objective of such projects, they'd be using a language with superior language building tools (not necessarily Lisp, there are many alternatives, it's just that neither C nor C++ are good at it).

Re: Rust in QEMU Roadmap

#162

Post by bobajeff »

qalmakka wrote: post #152
bobajeff wrote: post #43

Earlier quoted context omitted.

The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.

Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.

It makes sense if you consider that it was created for making c libraries bindable to higher level languages. That's more a flaw in it's design rather than implementation. If they were to design such a system now I'd hope it would be designed as a language independent ABI, Runtime and IDL like the Wasm Component Model.

Re: Rust in QEMU Roadmap

#163

Post by School-Cotton »

jdefr89 wrote: post #105
School-Cotton wrote: post #62

Earlier quoted context omitted.

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

There is Zig and a couple others. Rust borrows those features from functional languages they aren’t new innovations by any means..

Zig isn't really mainstream and I don't know of any functional languages without a garbage collector.

Re: Rust in QEMU Roadmap

#164

Post by aapoalas »

bonzini wrote: post #17
aapoalas wrote: post #15

Earlier quoted context omitted.

Can you link the script? This sounds vaguely like something that would be no skin off my back, so I'd be quite happy to help with this.

Yes it's https://github.com/qemu/qemu/tree/master/scripts/tracetool . I also found https://github.com/cuviper/probe-rs/tree/master/src/platform which seems interesting.

Here's my WIP addition to Oxide Computer's usdt crate: https://github.com/oxidecomputer/usdt/pull/340

This crate gives you a nifty macro that translates Rust probe definitions into the correct ELF sections and other related assembly. Other ways to declare probes are also supported, though.

Their support is currently only for illumos and OS X but I managed to get Linux SystemTap SDTs working as well, and a PR for FreeBSD exists as well but has been languishing in review purgatory for two years: I imagine QEMU might enjoy this wide support (if they land).

Re: Rust in QEMU Roadmap

#165

Post by School-Cotton »

0x457 wrote: post #83
ronsor wrote: post #68

Earlier quoted context omitted.

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

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

Re: Rust in QEMU Roadmap

#166

Post by School-Cotton »

uecker wrote: post #131
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.

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.

Re: Rust in QEMU Roadmap

#167

Post by keybored »

akira2501 wrote: post #122
keybored wrote: post #114

Earlier quoted context omitted.

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

Apologies are in order. I thought you were the original poster.[1] Your comment wasn’t as inappropriate. Although everything is relative.

I’m perfectly happy with appealing to authority when you respond to Josh Tripplet’s point about the author being a longtime contributor with these weird followup questions about “biggest?” and whatever, which in turn was a followup to the bizarre statement about invading projects ([1] again). Linus Torvalds is fine with the Rust in the Kernel experiment. This author is a longtime Linux contributor. So yes indeed: who are you to question Rust in the Kernel project?

To unpack a bit. Everything can be questioned. But with some sort of temperance and perspective. Talking about pushing “hacks upstream” is over the top and unfounded considering the context (what you call appeal to authority).

It would be appropriate if these were outsider upstarts that didn’t have a history in this project. But it aint.

[1] https://news.ycombinator.com/item?id=42303721

Re: Rust in QEMU Roadmap

#168

Post by keybored »

uecker wrote: post #131
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.

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.

Read what the “safe” means. It is narrow. Memory safety.

Re: Rust in QEMU Roadmap

#169

Post by keybored »

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…

Again and again we see the detractors complaining about Rustaceans being out of control, zealots... meanwhile the only once being unreasonable and making side-topics language war subthreads are the complainers.

What I’ve seen outside these subthreads is just people discussing Rust in the Kernel. No zealotry side-topics about how Rust should be used in place of C or C++ or other such advocacy side-topics.

It’s just embarrasing at this point.

Re: Rust in QEMU Roadmap

#170

Post by jodrellblank »

bluGill wrote: post #99
jodrellblank wrote: post #64

Earlier quoted context omitted.

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

I'm also not a Rust programmer so I can't comment on whether people are overusing it, I was commenting on the suggestion that "if you're using unsafe{} in Rust what's the point in using Rust at all?" implying that it's basically C at that point, and it isn't - there's still a lot of safety checks the compiler does even in unsafe mode.
Post reply on HN