Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

761–770 of 853 posts

Re: Rust in the kernel is no longer experimental

#761

Earlier quoted context omitted.

That works for functions. For datatypes that are used throughout the API, it does not work so well.

Wouldn't a data type with no safe method of construction satisfy that? You can only get one by calling an unsafe function & satisfying its constraints.

That would be possible but also make its usage unergonomic and not the experience customers are expecting when requesting a Rust API.

Re: Rust in the kernel is no longer experimental

#762
post #425

Earlier quoted context omitted.

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

Well, GCC 15 already ended support for the nios2 soft-core. The successor to it is Nios V which runs RISC-V. If users want us update the kernel, they'll also need to update their FPGA. Microblaze also is a soft-core, based on RISC-V, presumably it could support actual RISC-V if anyone cared. All others haven't received new hardware within the last 10 years, everybody using these will already be running an LTS kernel…

You fell into the trap I predicted a few years ago when the renaming happened. Microblaze refers to the old microblaze soft core, not the new one that they named the same thing and that is based on RISCV.

Re: Rust in the kernel is no longer experimental

#763

Earlier quoted context omitted.

Is there any evidence "Asahi Lina" is Hector?

At this point I suspect anyone who even asks that question of concern trolling. The evidence is overwhelming.

That's a weird way to avoid providing evidence :)

Re: Rust in the kernel is no longer experimental

#764

Earlier quoted context omitted.

Is there any evidence "Asahi Lina" is Hector?

There is. You can easily find by googling "hector martin" "asahi lina" and you will soon find a pile of obsessively archived evidence. My view, now that Hector has resigned from the LKML both as himself and as Lina, is there is no problem any more. If Hector wants to project a persona, or decide his identity is the persona, or maybe multiple personas, that is fine on social media. People do that. So long as he's not…

Instead of prompting me to "do my own research" (spoiler: The 'evidence' is lacking and is mostly tedious speculation) you could provide something more compelling

Re: Rust in the kernel is no longer experimental

#765

Earlier quoted context omitted.

Is there any evidence "Asahi Lina" is Hector?

Thank you for asking this. It was presented matter of fact and I would not have appreciated that it was something less than settled. The best I can find from googling was rumors and speculation (insert comment in reply with more rumors and speculation). I also don't necessarily think it means someone is a Bad Guy if true. I want people to be able to have anonymous alter egos online if that's what they want and they'r…

Being called a "concern troll" for daring to question such a bizarre accusation makes me think it's just a bunch of weird losers

Re: Rust in the kernel is no longer experimental

#766
post #396
post #74

Earlier quoted context omitted.

I'm not on the Rust bandwagon, but statements like this make absolutely no sense. A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead. It's only been in the last few years we've see…

As everybody knows not a single programming language was released between C++ and Rust.

By the 90s/early 2000s C/C++ were the only widely used languages that met my criteria. Rust is the first "modern" language to meet that criteria while simultaneously offering memory safety.

If you could afford garbage collection you had plenty of options.

Re: Rust in the kernel is no longer experimental

#767
post #74

Earlier quoted context omitted.

I'm not on the Rust bandwagon, but statements like this make absolutely no sense. A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead. It's only been in the last few years we've see…

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

Re: Rust in the kernel is no longer experimental

#768

Earlier quoted context omitted.

It is interesting how many very experienced programmers have not yet learned your lesson, so you may be young but you are doing very well indeed. Kudos.

Hah I’m not that young - it’s a figure of speech!

Either way, the point you are making is an excellent one. Discipline makes for better programming, and to not use the features available to you is very often the right choice.

Re: Rust in the kernel is no longer experimental

#769

I guess it's time to finally try FreeBSD.

Why? Are you allergic to running rust code? You know, you can’t actually tell when you execute a binary? I don’t like programming in Go, but nothing stops me running go programs on my computer. My computer doesn’t seem to care.

It's not about rust or no rust, rust is fine. It's about the constant drama.

Re: Rust in the kernel is no longer experimental

#770
post #639
post #177

Earlier quoted context omitted.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then R…

Not trying to make a value judgement on Rust either, just brainstorming why Rust changeover might go slow per the question. FWIW I work in firmware with the heap turned off. I’ve worked on projects in both C and Rust, and agree Rust still adds useful checks (at the cost of compile times and binary sizes). It seems worth the trade off for most projects.

Okay. That sounds like a reasonable explanation. Thanks!
Post reply on HN