Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

[RahulSundaram]

All communities will have vocal members disdaining other initiatives. That doesn't make them representative of the whole.

I would agree with you in general but in this topic, I find the discussions toxic and representative enough to be called out. I am far from the only person noticing it.

[mdedetrich]

In the absence of a stronger evidentiary claim, the simplest explanation is the far more likelier one: It is more likely than not that commercial organizations are investing in something for commercial reasons.

The strongest evidentiary claim is that apart from C/C++ which for largely historical reasons have different implementations (i.e. design by committee, compilers were created at a time when competing proprietary compilers was a thing) having multiple implementations of a language spec is almost certainly doomed for failure **especially if its open source** (they are counter examples such as Azul for JVM however that is a commercial product targeting a specific segment i.e. HFT, not really applicable here).

This is made even worse by the fact that Rust is not an easy language/compiler to implement, its going to face the same problem that Haskell and all of its alternate implementations (which are currently either dead or borderline dead) will face. Alternative implementations for modern open source languages that have started with a strong initial implementation almost always "fail", in fact I can't even come up with an example of one succeeding in recent 20 years. The closest one that comes to mind was JRuby (Ruby implementation on JVM) but the only real reason that was successful is at the time Ruby had terrible support for concurrency which the JVM was alleviating, JRuby is now almost dead since official Ruby implementation made improvements so its still a moot point. Even for incredibly popular languages like Python that have alternative implementations (i.e. PyPy) suffer similar issues.

Adding a different backend to Rust for GCC is the most sensible path forward, not reimplementing Rust especially considering Rust is a low level language.

Finally another counter point is its just going to create schism, you are going to have the normal official Rust and then the Linux kernel's (I can fairly safely say that only the kernel will really have a use for gcc-rs) and considering the complex problem space we are dealing with there are going to be deviations which is ultimately going to hurt the Linux kernel in the long run because there will be more friction in then having to deal with these differences and also having to account for them when specifically writing rust for the kernel.

[RahulSundaram]

The strongest evidentiary claim is that apart from C/C++ which for largely historical reasons have different implementations (i.e. design by committee, compilers were created at a time when competing proprietary compilers was a thing) having multiple implementations of a language spec is almost certainly doomed for failure **especially if its open source** (they are counter examples such as Azul for JVM however that is a commercial product targeting a specific segment i.e. HFT, not really applicable here)

Sorry, not buying that claim. GCC was already open source when Clang was developed. D has atleast three different major implementations, all open source and even more poc types. Lua has multiple implementations. JRuby unlike what you think has a very substantial user base including embedded within Puppet Server which is a widely deployed configuration management tool *and* independent of that. Mono continues to be developed and used in several places including Unity. Hack originally developed within Facebook as an alternative implementation of PHP continues to be deployed there and other places. Android only switched to using OpenJDK libraries because of the lawsuit but continues to use Dalvik. Oracle itself has GraalVM as an alternative implementation. Some alternatives including GNU Java (including full reimplementations of the standard libraries) which was used by Red Hat to build all the Java tooling including major codebases like Hadoop and Eclipse and commercially supported for many many years went away when OpenJDK happened but there are so many counter examples to not assume that alternative implementations are automatically doomed. Even if GCC-rs is only used for Linux kernel as you say, Linux kernel is hardly a small project you can just wish away. Rust community should be thrilled with the fact that Linux kernel has accepted Rust and then will have to accept that alternatives do exist to their favored implementation and play nice.

[linner]

I hope more people than just fanbois take the time to make sure these additions actually provide a benefit and not a negative.

[mdedetrich]

Sorry, not buying that claim. GCC was already open source when Clang was developed. D has atleast three different major implementations, all open source and even more poc types. Lua has multiple implementations. JRuby unlike what you think has a very substantial user base including embedded within Puppet Server which is a widely deployed configuration management tool *and* independent of that. Mono continues to be developed and used in several places including Unity. Hack originally developed within Facebook as an alternative implementation of PHP continues to be deployed there and other places. Android only switched to using OpenJDK libraries because of the lawsuit but continues to use Dalvik. Oracle itself has GraalVM as an alternative implementation. Some alternatives including GNU Java (including full reimplementations of the standard libraries) which was used by Red Hat to build all the Java tooling including major codebases like Hadoop and Eclipse and commercially supported for many many years went away when OpenJDK happened but there are so many counter examples to not assume that alternative implementations are automatically doomed. Even if GCC-rs is only used for Linux kernel as you say, Linux kernel is hardly a small project you can just wish away. Rust community should be thrilled with the fact that Linux kernel has accepted Rust and then will have to accept that alternatives do exist to their favored implementation and play nice.

Firstly pointing out that GCC is open source doesn't detract from my original point which is that when C/C++ was created it was by design and practice that there were multiple implementations from the start. This was quite intentional because at the time there was a lot more ISA's/architectures then now and so it was expected to have so many different implementations (now with LLVM this is becoming less of a feature albeit there are still use cases which LLVM doesn't cover). GCC was created as a reaction to the commercial compilers that existed but my whole point is that the development model and the design of the language and circumstances around the time allowed for that.

Secondly a lot of your examples are either invalid or not apt comparisons. JRuby is pretty much dead, I know because I used it and there was even a call for maintenance not long ago because it was only being updated by half a person.

In your other examples such as GraalVM (which I use), its actually providing a different feature that the original implementation doesn't. GraalVM allows you to create native exectuables (JVM cant), JRuby allows you to run on the JVM, etc etc. On the other hand, gcc-rs isn't doing anything different then a gcc backend in Rust, its still going to create binaries from the Rust language. The only difference is that adding a separate GCC backend to Rust is by far the most sensible solution because you don't have to worry about deviations/corrections in the spec of Rust, the only thing you have to worry about is the gcc backend being correct which is much smaller in scope. As a bonus since its the same codebase if you figure out problems with the gcc backend its easier to isolate what the problem is (i.e. LLVM deviating somehow from GCC?)

This is honestly one of the worst examples of duplicated effort that I can think of, I mean if official rustc was hypothetically singlecore and the gcc version was multicore than I could understand it, or like with the JRuby/JPython examples I mentioned earlier where they fixed the various concurrency problems that either cannot be fixed in the original implementations (Python spec mandating GIL) or hard to fix (Ruby).

All I see here is NIH/everything must be in GCC syndrome.

[RahulSundaram]

All I see here is NIH/everything must be in GCC syndrome.

I understand you feel that way. Nevertheless, there are multiple thriving implementations of several comparable languages that are widely used now. That's just a fact. Therefore, attempts to dismiss alternative implementations of Rust as automatically doomed is premature. We will have ample time to see for ourselves in a few years and we can table this conversation for now.