Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

221–230 of 853 posts

Re: Rust in the kernel is no longer experimental

#221

Post by ViewTrick1002 »

biorach wrote: post #196
ViewTrick1002 wrote: post #164

Earlier quoted context omitted.

Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library. https://doc.rust-lang.org/src/alloc/collections/linked_list....

Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig…

The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface.

If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way.

That is how all standard library collections in Rust works. They’ve just gone to the length of formally verifying parts of the code to ensure performance and safety.

Re: Rust in the kernel is no longer experimental

#222

Post by tomnipotent »

dwattttt wrote: post #182
tomnipotent wrote: post #162

Earlier quoted context omitted.

I'm unaware of any such marketing.

Zig does claim that it > ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".

That's a library feature (not intended for release builds), not a language feature.

Re: Rust in the kernel is no longer experimental

#223

Post by gjajric »

debugnik wrote: post #158
sho_hn wrote: post #58

Earlier quoted context omitted.

I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.

> most existing Rust developers are not "blank slate Rust developers" Not most, but the pool of software devs has been doubling every five years, and Rust matches C# on "Learning to Code" voters at Stack Overflow's last survey, which is crazy considering how many people learn C# just to use Unity. I think you underestimate how many developers are Rust blank slates. Anecdotically, I've recently come across comments fr…

[dead]

Re: Rust in the kernel is no longer experimental

#224

Post by SSLy »

teruakohatu wrote: post #205
jcranmer wrote: post #32

Earlier quoted context omitted.

There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran,…

> There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash Java, really? I don’t think Java has been essential for a long time. Is Perl still critical?

It's extremely hard to build any unixly userspace without perl dependencies.

Re: Rust in the kernel is no longer experimental

#226

Post by baq »

Yiin wrote: post #128
thayne wrote: post #30

Earlier quoted context omitted.

> very slow compilation times That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.

typescript transpilation to js is nearly instant, it's not comparable

Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.

Re: Rust in the kernel is no longer experimental

#227

Post by gjajric »

mmooss wrote: post #53
sho_hn wrote: post #41

Earlier quoted context omitted.

I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.

People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things. I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to mak…

According to the strange data at https://survey.stackoverflow.co/2025/technology#most-popular... , 44.6% have responded positively to that question regarding C++. But there may be some issues, for the question involves two check boxes, yet there is only one statistic.

Re: Rust in the kernel is no longer experimental

#228

Post by hulitu »

hmry wrote: post #206
jenadine wrote: post #183

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)

luckily downloading a specific nightly version is only a single rustup command

Besides supply chain attacks, what could go wrong ? /s

Re: Rust in the kernel is no longer experimental

#229

Post by pjmlp »

markus_zhang wrote: post #11

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

Yes it does, alongside C++, Rust isn't available everywhere.

There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon.

POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,...

Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded.

Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence.

Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.

Re: Rust in the kernel is no longer experimental

#230

Post by jfjfnfjrh »

jcranmer wrote: post #32
drnick1 wrote: post #14

Earlier quoted context omitted.

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran,…

Debian and Ubuntu enter the chat.....
Post reply on HN