Hacker News Reader

Comment by dragonsh | Hacker News Reader

Rust is not close to hardware as C is, so if need to do anything with hardware Rust still relies on majority of the code written in C. Performance wise today C is still faster than Rust in general.

Rust is still a decade or more away from anything serious like C. Majority of the functional Rust libraries today depend on underlying C libraries.

Rust may try to replace C++ but replacing C is far away dream.

Let's wait when Mozilla (origin and major supporter for Rust language) can release Firefox in Rust, until than it's still a popular experiment in systems programming area.

Rust does not run any critical component like Linux Kernel today, when it will be able to do it than it can be considered as real systems programming language challenger to C. Right now most of it's safety guarantees are not really battle tested like C.

View on HN

> Rust is not close to hardware as C... Performance wise today C is still faster than Rust in general.

On what basis do you say this?

> Let's wait when Mozilla (origin and major supporter for Rust language) can release Firefox in Rust,

Firefox has shipped rust code since August 2016 with the release of Firefox 48.

> Rust does not run any critical component like Linux Kernel today,

This depends on how you define "critical component." At this point, there is a lot of Rust in a lot of critical pathways for a lot of things.

Incidentally, the kernel maintainers have suggested that they're open to the possibility of Rust in optional drivers. See my other comment below.

Rust has a thriving embedded ecosystem[1]. You have access to an ever growing number of HALs[2]. There is an embedded operating system written entirely in Rust called Tock [3], and it can run things like OpenSK, an open source security key application. [4]

[1] https://www.rust-lang.org/what/embedded

[2] https://github.com/rust-embedded/embedded-hal

[3] https://www.tockos.org/

[4] https://www.tockos.org/blog/2020/hello-opensk/

I've run Rust on a Nintendo 64 with no C and the same amount of asm you'd need in a C codebase.

> Rust is not close to hardware as C

What does that entail exactly? And why is it a "good thing" to be close to the hardware even if we were to accept that statement?

"Rust does not run any critical component like Linux Kernel..." - and the only reason why it is not happening (provided that C and Rust have perfect interoperability, more and more C/C++ developers get familiar with Rust) is the fact that Linus Torvalds convinced by voices from Ethernet socket not to use anything but C. I can't wait for him to retire so that Linux kernel devs could pick up more modern toolset

Incidentally, back in 2016: https://www.infoworld.com/article/3109150/linux-at-25-linus-...

> What do you think of the projects currently underway to develop OS kernels in languages like Rust (touted for having built-in safeties that C does not)?

> That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.

> I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.

As much as I love Rust: As long as Rust doesn't support all platforms which the Linux kernel supports, it really is a no-go for kernel code in general.

"in general" is a bit strong; the maintainers have said:

> I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't need Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs.

https://lwn.net/Articles/797828/

That's why I wrote "in general": It's not yet suitable for most kernel code, just for some specific cases (i.e., optional drivers).

Hmm, maybe I should have written "...for general kernel code" or "...for most kernel code", that would have been clearer.

Ah yeah, I see that now... words are hard, I think you can read this both ways. Sorry about that!

Reply on news.ycombinator.com