From one of those posts:

> I don't see how the two languages might coexist peacefully without rust toolchain being necessary for building any kernel useful in practice and anyone seriously involved in kernel development having to be proficient in both languages.

I can empathise with that. Just last week I butted head with an issue in a python package that requires Rust internally. The lib compiles fine on its own, but something gets screwed when running in a virtualenv. Opened a bug in github, and nobody has any idea about how to get even a detailed log out of the rust toolchain.

I'm sympathetic about Rust, I really am. But sprinkling it mindlessly everywhere is a big risk.

> The more you make it look like (Kernel) C, the easier it is for us C people to actually read. My eyes have been reading C for almost 30 years by now, they have a lexer built in the optical nerve; reading something that looks vaguely like C but is definitely not C is an utterly painful experience.

I think he makes a good point about the fact that it's certainly possible the Rust code written today won't still compile in 10 years, but writing Rust in C-style seems like a terrible approach. Write using the idioms of the language used.

> I think he makes a good point about the fact that it's certainly possible the Rust code written today won't still compile in 10 years

It’s possible but unlikely. The Editions feature [1] has been specifically designed to provide longevity.

[1]: https://doc.rust-lang.org/edition-guide/editions/index.html

Section 3.16 ("Platform and target support") of the linked document is so inadequate for Linux kernel related questions, such as "what compilation targets will be supported by this Rust Edition in 10 years", that there is nothing to quote to show it's inadequate. It doesn't even tell what compilation targets are supported right now.

The canonical link for platform support is here: https://doc.rust-lang.org/stable/rustc/platform-support.html

There is no commitment to keeping the platforms in tier 1, 2 or 3 for any length of time or to provide advance warning before platforms are degraded, not to mention that the tier 1 list is vastly insufficient (Arm64, x86, x86_64).

Rustc is clearly meant to compile Rust applications and use for the Linux kernel, which from the point of view of this document would be narrower than tier 1, is highly experimental.

Where does Linux document how long platforms are guaranteed support? My understanding is there's not either.

(And yes, we'd love to expand the tier list. It's a chicken and egg situation. That being said, I work mostly in tier 2 and 3 targets, and they just vary a lot. The ones I work in work as good as tier 1 targets do. The path to moving forward is bright for many of these.)

> Rustc is clearly meant to compile Rust applications

I don't see what about this implies that at all. As a core team member and someone writing an embedded OS at work, I can assure you that we don't think of Rust as purely an application language.

Maybe I'm unfamiliar with Rust, but if you list OSX, Linux and Windows on identical processors as different platforms they are platforms for applications, not for an OS kernel that runs on "bare metal": it implies that support includes relying on OS provided system calls to manage processes, implement the standard library, etc.

Sure, the standard library on those targets depends on OS services. But you don’t have to use the standard library. Many people do write userspace programs in Rust, just like they do in C. That doesn’t mean that it’s only useful or intended for userspace, just like C.

It takes more work to port an entire standard library than to not.

unless you plan to run `rustc` as a kernelspace application, anything in tier 2 (`core`, `alloc`, maybe `std` all compile and likely pass tests) is sufficient

Personal pet peeve: new people who come into a project without any context and use their own idiosyncratic code style. :-)

I agree, but if it helps creating more and better drivers, it might be a good thing considering the lifetime of the target hardware matches Rust lifetime.

>>> I could be mistaken but you seem angry. Perhaps it wouldn't be a bad idea to read your own code of conduct

A passive-aggressive "you mad bro?" followed by namechecking the coc, all in service of doubling down on antagonizing someone over their choice in workflow? Good grief.

“CoC” seems to suffer from the same problem that “bad cops” and “zero tolerance” politicians seem to suffer from, so that's why it's often brought up.

It seems to be a common thing that those that demand the strictest morality rules also seem to have the most aggression problems and often overstep their own rules, but typically have an excuse ready why in their case it's different.

Though, perhaps it simply stands out more if it's one to chant “code of conduct” or “zero tolerance”, but as far as statistics in the Dutch parliament goes, it's often pointed out that all the parties that are in favor of lighter punishments and rehabilitation tend to be spot free, whereas politicians of parties that advocate harsh punishments and zero tolerance tend to very often have past criminal records themselves.

Not sure why this is down-voted. At the very least the people who invoke the CoC are among the most pushy and dominant ones in projects, even when they manage to cloak the dominance so as not to be perceived to be aggressive.

U.S. people are better at that game, since it is expected and rewarded in work life. This is also why they push for CoCs, which have nothing to do with manners or niceness, but are just another power tool.

I have never seen a genuinely nice person push for a CoC. Not once.

> Not sure why this is down-voted.

What I just considered due to your post is that it's quite likely that those who support C.o.C.s are also more likely to cast votes.

I think it quite likely that those with a libertarian life philosophy are far less likely to cast votes on websites in general, especially to voice disagreement.

I concur that those who want enforced niceness seldom are nice themselves and tend to often have their reasons and excuses of why they are justified when they are not so nice.

Most bad thing starts with very good intention.

The use of CoC might be one of them.

Bad intentions don't exist; the bad guy always sees himself as the good guy.

The zero tolerance politician with a domestic violence conviction probably believes that in his case it was different and justified, just as everyone with a domestic violence conviction does.

The person he responded to had all but told him to go to hell in the previous email. Seems like a reasonable response to an unreasonable email

Eh I'm normally against bludgeoning people with a CoC, but the guy he responded to was basically telling him to "go fuck yourself" masked by euphemisms. So I think this was just a passive-aggressive response in kind to a rude email.

The CoC is working as designed.

Oh I love this bit in [1]

I've yet to see a program that renders HTML (including all the cruft often used in docs, which might include SVG graphics and whatnot) sanely in ASCII. Lynx does not qualify, it's output is atrocious crap.

Yes, lynx lets you read HTML in ASCII, but at the cost of bleeding eyeballs and missing content.

Nothing beats a sane ASCII document with possibly, where really needed some ASCII art.

Sadly the whole kernel documentation project is moving away from that as well, which just means I'm back to working on an undocumented codebase. This rst crap they adopted is unreadable garbage.

Rust's strengths lie where Rust is written like Rust. If Linus wants C, he knows where to find it. Rust isn't for "C people" -- it's for their replacements.

Winning friends and influencing people