Live data from Hacker News

Chrome OS KVM - A component written in Rust

chromium.googlesource.com

31–40 of 109 posts

Re: Chrome OS KVM - A component written in Rust

#31
post #17
post #13

Earlier quoted context omitted.

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Null is not really the most pertinent example in this context - at least you get a segfault. What is more important is that in C or C++ (even C++17), it is trivially easy to produce buffer overruns, use after frees, dangling pointers, invalidated iterators, data races etc. That is the unsafety that we are talking about here. Opt-in nullability via Option is nice to have though.

> at least you get a segfault

If the platform has an MMU, if you've properly set up your page table mappings, etc. We are talking about writing an OS here!

Not to mention all the UB around null pointers that can cause miscompilation. Well, not technically miscompilation, but stuff like https://news.ycombinator.com/item?id=15324414

Re: Chrome OS KVM - A component written in Rust

#32
post #23
post #19

Earlier quoted context omitted.

Yeah, I went with familiarity/simplicity in that example. My point was similar C/C++ don't have a safe subset.

Not a safe subset anyone would want to use at least. You could just not use pointers in your code and you'd have memory safety.

Your code, or any of the code it calls; iterator invalidation, for example, wouldn't force you to use pointers directly, but can still cause memory unsafety.

Re: Chrome OS KVM - A component written in Rust

#33
post #26
post #22

Whether you want Rust to go or, Go to rust

I see a place for both of them in my toolbox. Go still makes network code and certain models of concurrency stupidly simple. Rust is more of a replacement for C/C++ for me.

Go confirmed for me what I suspected: which is that I hate hate hate the futures style of async programming.

I'm on the lookout for channels and green-threads in Rust (so I can basically write borrow-checked Go-style code in Rust).

Re: Chrome OS KVM - A component written in Rust

#34
post #30

Earlier quoted context omitted.

Can you expand upon what makes Rust more energy efficient than C or C++? What are the language properties that enable Rust code to be more energy optimised?

It's not even ranked first. Rust comes a good second to third behind C & C++ on most if not all tests listed on https://sites.google.com/view/energy-efficiency-languages/re...

"one of the most energy efficient" + "safe"

Re: Chrome OS KVM - A component written in Rust

#35
post #30

Earlier quoted context omitted.

Can you expand upon what makes Rust more energy efficient than C or C++? What are the language properties that enable Rust code to be more energy optimised?

It's not even ranked first. Rust comes a good second to third behind C & C++ on most if not all tests listed on https://sites.google.com/view/energy-efficiency-languages/re...

In the normalized global results, at the bottom, Rust is above C++, and closer to C than C++ is to it.

Re: Chrome OS KVM - A component written in Rust

#36
post #16
post #13

Earlier quoted context omitted.

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

thankfully C++ has references.

References can still be null.

Re: Chrome OS KVM - A component written in Rust

#37

Isn't stuff like that exactly counteracting Rusts raison d'etre? > // This is safe; nothing else will use or hold onto the raw sock fd. > Ok(unsafe { net::UdpSocket::from_raw_fd(sock) }) https://chromium.googlesource.com/chromiumos/platform/crosvm...

That's low-level code implementing a wrapper around the underlying libc socket API; there's no alternative to unsafe blocks there as it wraps a legacy API written in C.

The "this is safe" comment is just a (very verbose) explanation as to why the wrapper code is doing the correct thing. Notably, there's another similar comment just above it. In fact, looking through the file if anything I'm quite impressed at how carefully it's written.

Re: Chrome OS KVM - A component written in Rust

#38
post #3
post #2

The Fuchsia OS microkernel should be rewritten in Rust, too, especially if it's going to take another 5 years before we even see it in a commercial product. If Google wants to make a modern new OS that will help it avoid many of the existing security problems it needs to keep fixing with Android/Chrome OS right now, then it should do it right and avoid collecting a lot of "security debt" down the road because of unsa…

You absolutely right! You can imagine what Google can do with his resources when even one programmer writes his own OS, file system, etc on Rust - https://github.com/redox-os/ !

What is the connection between Google and Redox?

I didn’t understand you to be honest.

Re: Chrome OS KVM - A component written in Rust

#39

Isn't stuff like that exactly counteracting Rusts raison d'etre? > // This is safe; nothing else will use or hold onto the raw sock fd. > Ok(unsafe { net::UdpSocket::from_raw_fd(sock) }) https://chromium.googlesource.com/chromiumos/platform/crosvm...

Not sure why you're downvoted because it's a perfectly reasonable question.

Rust's safety guarantees are mostly there to prevent you from making a certain class of coding errors. "unsafe" means that you've disabled those protections, but that just means that you have to be extra careful not to make those mistakes, and that people reviewing your code need to spend extra time to make sure that you haven't made those mistakes.

Re: Chrome OS KVM - A component written in Rust

#40
post #30

Earlier quoted context omitted.

Can you expand upon what makes Rust more energy efficient than C or C++? What are the language properties that enable Rust code to be more energy optimised?

It's not even ranked first. Rust comes a good second to third behind C & C++ on most if not all tests listed on https://sites.google.com/view/energy-efficiency-languages/re...

This is more a reflection of where the compiler is at, not the language. As a compiled, strongly-typed language without a GC, there is no theoretical reason why Rust could not be faster than C++. As the use of MIR and HIR (two intermediate languages used within the compiler) increases more optimizations taking advantage of the memory model could be added.

In the current state, much of that work is left to LLVM which is designed more around the C/C++ memory model and only some of the ownership and aliasing information can be represented in that form.

I am not arguing that Rust is faster now, only that it can be without fundamentally changing the language.

Post reply on HN