Rust v10 Patches Posted Ahead Of Expected Merging With Linux 6.1

[marios]

Having a strong opinion against merging Rust in the kernel, I think I have to comment on that.

Well it is a fact that the syntax of Rust sucks and there are objective arguments for that (for example verbosity). But this is not the reason I believe it should stay out of the kernel. The two main reasons I strongly believe that are:
0. Having more than one languages in an already complicated project will make things even more complicated. I don't care if the other language is Rust or C++ or an imaginary ultra performing, nicely syntaxed, hyper safe language. It can only bring more harm than good.
1. I am stealing Linus' quote here, and am changing some words to express my point. "Quite frankly, even if the choice of C were to do *nothing* but keep the Rustafarians out, that in itself would be a huge reason to use C". The last thing needed in the kernel are those javaspawns...

PS. Linux is going downhill since Linus became a google cultist. Merging Rust might just be the death warrant of Linux. Maybe it's time to start a new kernel project, just like Linus did in the 90s...

[ryao]

PS. Linux is going downhill since Linus became a google cultist. Merging Rust might just be the death warrant of Linux. Maybe it's time to start a new kernel project, just like Linus did in the 90s...

Rust was made by Mozilla. Go was made by Google.

That said, I imagine you could be happier with FreeBSD.

[mdedetrich]

I think that the syntax is a design flaw in Rust. Notions like "ugly" or "easy on the eye" are subjective, but the main problem with Rust's syntax IMHO is that it tries too hard to look familiar to C++ coders while the semantics are sometimes radically different. That leads to unnecessary confusion and makes Rust look more difficult to learn than it really is. It's also unnecessarily verbose, redundant and at the same time cryptic for basically no reason at all (other than again to look vaguely like C++). The ship has long sailed now and of course nothing about the syntax is a dealbreaker, but for a language with such strong ML influence, a more ML-like syntax would perhaps have been more natural and more user friendly.

I agree with this completely and it was even stated that the explicit goal of Rust's syntax was just to make it familiar to C++ programmers in order to bring them over. Not sure how valid that reason but as you stated its too late now.

Having a strong opinion against merging Rust in the kernel, I think I have to comment on that.

Well it is a fact that the syntax of Rust sucks and there are objective arguments for that (for example verbosity). But this is not the reason I believe it should stay out of the kernel. The two main reasons I strongly believe that are:
0. Having more than one languages in an already complicated project will make things even more complicated. I don't care if the other language is Rust or C++ or an imaginary ultra performing, nicely syntaxed, hyper safe language. It can only bring more harm than good.
1. I am stealing Linus' quote here, and am changing some words to express my point. "Quite frankly, even if the choice of C were to do *nothing* but keep the Rustafarians out, that in itself would be a huge reason to use C". The last thing needed in the kernel are those javaspawns...

PS. Linux is going downhill since Linus became a google cultist. Merging Rust might just be the death warrant of Linux. Maybe it's time to start a new kernel project, just like Linus did in the 90s...

We know you have a strong opinion. It also happens to make no coherent sense because its full of conspiracy theories and non problems created by someone who evidently cannot program.

[mdedetrich]

What I really don't understand is why do people bitch at Perl for being ugly but they're ready to jump ship for Rust, which has just as ugly and enigmatic syntax as Perl.

People don't bitch at Perl for being ugly, actually in terms of syntax its quite nice. What people bitch at perl about is that because it has no many shorthands of doing very specific things its quite frequent that when you write a Perl program you can't really understand what it does when you read it a few months later.

[jacob]

Having a strong opinion against merging Rust in the kernel, I think I have to comment on that.

Well it is a fact that the syntax of Rust sucks and there are objective arguments for that (for example verbosity). But this is not the reason I believe it should stay out of the kernel. The two main reasons I strongly believe that are:
0. Having more than one languages in an already complicated project will make things even more complicated. I don't care if the other language is Rust or C++ or an imaginary ultra performing, nicely syntaxed, hyper safe language. It can only bring more harm than good.
1. I am stealing Linus' quote here, and am changing some words to express my point. "Quite frankly, even if the choice of C were to do *nothing* but keep the Rustafarians out, that in itself would be a huge reason to use C". The last thing needed in the kernel are those javaspawns...

PS. Linux is going downhill since Linus became a google cultist. Merging Rust might just be the death warrant of Linux. Maybe it's time to start a new kernel project, just like Linus did in the 90s...

0: Most if not all projects that at least approach Linux is scale and complexity already use multiple languages. It is true that it adds some intrinsic complexity but that's not an argument by itself, it must be pondered against the benefits that using those languages brings to the project overall. Whether Rust will prove beneficial to the Linux kernel remains an open question but we won't know until it's tried. That's also the reason why it's still officially considered experimental.

1. Linus said that about C++ coders but he doesn't seem to mind Rustafarians. Do you see something he doesn't?

PS: I think most OSes would love to go "downhill" like Linux does, but there already are many new kernel projects for you to pick from. Or you can fork Linux like Linus forked Minix.

[RahulSundaram]

PS: I think most OSes would love to go "downhill" like Linux does, but there already are many new kernel projects for you to pick from. Or you can fork Linux like Linus forked Minix.

Careful there, Linus did not fork Minix. Minix had a different more restrictive license then. Linus wrote Linux from scratch instead. In fact, part of SCO FUD was that Linux was derivative of Minix, stole code etc that it has been even been addressed in the Minix FAQ.

[ssokolow]

1. Linus said that about C++ coders but he doesn't seem to mind Rustafarians. Do you see something he doesn't?

In the interest of accuracy, the moniker is "Rustaceans", from the fact that the official mascot is a crab.

...plus, I imagine "Rustafarians" might be seen as disrespectful to Rastafarians, and the Rust team and moderators care about that sort of thing.

[rmoog]

People don't bitch at Perl for being ugly, actually in terms of syntax its quite nice. What people bitch at perl about is that because it has no many shorthands of doing very specific things its quite frequent that when you write a Perl program you can't really understand what it does when you read it a few months later.

And that's exactly my first impression upon seeing Rust code. I needed to write some patches for it and my first impression was that someone was trying their hardest to invent a language to rival the obscure and mysterious nature of Perl. But then again, people wrote in Perl because it paid well. Must be the same with Rust. Right? Or is Rust a language for jannies?

[rmoog]

Having a strong opinion against merging Rust in the kernel, I think I have to comment on that.

Well it is a fact that the syntax of Rust sucks and there are objective arguments for that (for example verbosity). But this is not the reason I believe it should stay out of the kernel. The two main reasons I strongly believe that are:
0. Having more than one languages in an already complicated project will make things even more complicated. I don't care if the other language is Rust or C++ or an imaginary ultra performing, nicely syntaxed, hyper safe language. It can only bring more harm than good.
1. I am stealing Linus' quote here, and am changing some words to express my point. "Quite frankly, even if the choice of C were to do *nothing* but keep the Rustafarians out, that in itself would be a huge reason to use C". The last thing needed in the kernel are those javaspawns...

PS. Linux is going downhill since Linus became a google cultist. Merging Rust might just be the death warrant of Linux. Maybe it's time to start a new kernel project, just like Linus did in the 90s...

As former package maintainer who had to write some Rust, I must say that Linux is going to enter a situation where it will need 2 compilers and the Rust compiler will be misbehaving a lot. Your choice of Rust code against Rust compiler is key to success because let's say your code has no documentation for functions and the Rust compiler will throw mysterious errors at you instead of telling you that you need to write documentation in the source code for the offending piece of code. What kind of crazy concept is this, anyway? Documentation is meant to go into man pages of Confluence pages, not source code.

[ssokolow]

And that's exactly my first impression upon seeing Rust code. I needed to write some patches for it and my first impression was that someone was trying their hardest to invent a language to rival the obscure and mysterious nature of Perl. But then again, people wrote in Perl because it paid well. Must be the same with Rust. Right? Or is Rust a language for jannies?

Quite the opposite. Yes, there are some novel language constructs, a bunch of syntax borrowed from the ML family of languages, and a bunch of concepts taken from the world of functional programming (and I'd be happy to explain things to you if you point to which ones you found confusing), but Rust is laser-focused on making sure that you don't need to be an expert to work on a codebase without breaking things.

As former package maintainer who had to write some Rust, I must say that Linux is going to enter a situation where it will need 2 compilers and the Rust compiler will be misbehaving a lot. Your choice of Rust code against Rust compiler is key to success because let's say your code has no documentation for functions and the Rust compiler will throw mysterious errors at you instead of telling you that you need to write documentation in the source code for the offending piece of code. What kind of crazy concept is this, anyway? Documentation is meant to go into man pages of Confluence pages, not source code.

As someone who actually writes Rust, I have no idea what you're talking about when you say "will throw mysterious errors at you instead of telling you that you need to write documentation in the source code for the offending piece of code".

The only thing it throws "mysterious errors" at you for is type system errors in code with a lot of generics, and they're less mysterious than those C++ throws. (And, more generally, anything that could be complained about in Rust's type system can and was complained about when languages like C forced assembly language programmers to adopt a structured programming model, where functions can only have one entry point (no GOTOing into the middle of a function from outside) and types are on values rather than operations.)

In fact, Rust is downright famous for taking the crown from Eiffel for most helpful error messages a compiler can present to you.

The only thing I can think of that is "documentation in the source code" is rustdoc, which is no different from Doxygen for C and C++, JavaDoc for Java, etc. except that there's one officially blessed documentation tool that's installed as part of the default toolchain.

As for what sounds vaguely like a complaint about the Rust compiler having poor forward compatibility, it does not. It has a policy of much stricter forward compatibility than C and C++ compilers, to the point where they have a buildbot named Crater which can build and run unit tests against giant slices (including "all") of the crates.io catalogue to evaluate a proposed change. The only reason you need more than one compiler version is if the project is using the nightly channel and API-unstable features that not only need nightly, but also a #![feature(...)] declaration in the source code or -Z... flag at the command line to activate them. (Yes, Firefox and Rust-for-Linux are doing that, but you can't blame the Rust toolchain developers for what is analogous to requiring GCC patches that haven't been accepted upstream yet.)