Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RahulSundaram
    replied
    Originally posted by mdedetrich View Post

    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.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by RahulSundaram View Post

    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.
    Last edited by mdedetrich; 27 June 2022, 09:51 AM.

    Leave a comment:


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

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by mdedetrich View Post

    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.
    Last edited by RahulSundaram; 25 June 2022, 06:17 PM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by RahulSundaram View Post

    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.
    Last edited by mdedetrich; 25 June 2022, 11:40 AM.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by sinepgib View Post

    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.
    Last edited by RahulSundaram; 24 June 2022, 09:13 AM.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by RahulSundaram View Post
    A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.
    All communities will have vocal members disdaining other initiatives. That doesn't make them representative of the whole.

    Leave a comment:


  • moltonel
    replied
    Originally posted by RahulSundaram View Post
    tldr: I consider it important to have alternative full implementation of major languages and it solves real problems which have increasingly become more important with the widespread issues associated supply chain verification and reproducibility. [...] I see from your replies that you don't consider the issues such as compiler attack vectors a priority or practical problem and we aren't going to agree on that, let's move on.
    That's fair enough, we disagree on how important it is. I do consider it important, but for example having Rust at all on more platforms is more urgent. Supply chain, reproducibility, bootstrapping have multiple solutions which can be explored in parallel and must be weighed for pros and cons. Full alternate implementations are just a mean to an end, make sure to keep the actual goals in mind.

    I would like the Rust community to completely drop all animosity against all free and open source implementations of the language be it mrust or gccrs.
    I have never seen any animosity towards mrustc, each update seems to receive a warm welcome. It is a comparatively simple compiler with the clear single purpose of bootstrapping rustc from C++, the community seems to agree on the goal and the method.

    Like many in the community I've made peace with gccrs, but it's important to understand where the animosity will still come from in the foreseeable future. It's not about duplication of effort, or about dislike of GNU or C++. It's about the very real risk of making rust harder to work with, because of small compiler differences. If that was the price to pay for better platform support or reinvigorated development, the community would accept the risk. But rustc_backend_gcc brings platform support without the risk, and rustc development is very healthy. Rust developers are a perfectionist bunch, the bar for gccrs to be "good enough to not be harmful" is very high. There's a good reason for the animosity, it's unlikely to die down.

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by RahulSundaram View Post

    A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.
    As you have said, it is only part of the community and it is still being developed on, so I see no problem here.

    The community of rust is fairly large, so you should expect to hear different voices and one that is against gcc-rs.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by NobodyXu View Post

    Both mrust and gccrs are being actively developed on, so I don't think the Rust community is against them.
    A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.

    Leave a comment:

Working...
X