Announcement

Collapse
No announcement yet.

There Are Renewed Discussions About Having Rust Language Support Within GCC

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

  • There Are Renewed Discussions About Having Rust Language Support Within GCC

    Phoronix: There Are Renewed Discussions About Having Rust Language Support Within GCC

    Going back a number of years has been various out-of-tree front-ends for GCC toying with the ability to compile Rust code with GCC while a new discussion has started up about the prospects of theoretically mainlining one of those efforts or otherwise developing a new GCC Rust front-end...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Having an independent implementation is important for many reasons and groups. It would be nice to see rust have such an implementation in GCC if a core community can be built to support it going forward after the resolution of the current troubles (i.e. first things first).

    Comment


    • #3
      This is happening because there was a thread recently on LKML discussing using Rust to write system drivers. This thread also lead to the recent switch by Hyperbola to a fork of OpenBSD.
      Last edited by jason.oliveira; 28 December 2019, 08:15 PM.

      Comment


      • #4
        I feel like this is going to be a bad move unless the rust devs give us a spec rather than the living language aproach

        Comment


        • #5
          So far, the plan seems to be using the existing front end and adding a gimple backend to MIR, in addition to llvm-ir. That way, the 'living language' isn't a problem.

          Bootstrapping gcc can then be done using mrustc.

          Comment


          • #6
            Originally posted by SpyroRyder View Post
            I feel like this is going to be a bad move unless the rust devs give us a spec rather than the living language aproach
            Hehe, remind me how old was C when it saw its first standardized version? Hopefully, if Rust proves its worth, it won't take as long, but it sure ain't gonna happen anytime soon. I'm not arguing that having a standard helps write a compiler, but standardizing so soon will only cripple development.

            I mean, imho Rust is nice and everything, but at this point it hasn't pinned down async/await, which, while not deal breakers to me, seem to be highly sought-after constructs in a modern language. And I'm pretty sure there are other things in the same position.

            Comment


            • #7
              Originally posted by bug77 View Post

              Hehe, remind me how old was C when it saw its first standardized version? Hopefully, if Rust proves its worth, it won't take as long, but it sure ain't gonna happen anytime soon. I'm not arguing that having a standard helps write a compiler, but standardizing so soon will only cripple development.

              I mean, imho Rust is nice and everything, but at this point it hasn't pinned down async/await, which, while not deal breakers to me, seem to be highly sought-after constructs in a modern language. And I'm pretty sure there are other things in the same position.
              "Voluminous documentation is part of the problem, not part of the solution" -- DeMarco, Tom, and Timothy Lister. "Peopleware: Productive projects and teams 2nd ed." New York, NY: Dorset House Publ (1999).

              Comment


              • #8
                Originally posted by bug77 View Post

                Hehe, remind me how old was C when it saw its first standardized version? Hopefully, if Rust proves its worth, it won't take as long, but it sure ain't gonna happen anytime soon. I'm not arguing that having a standard helps write a compiler, but standardizing so soon will only cripple development.

                I mean, imho Rust is nice and everything, but at this point it hasn't pinned down async/await, which, while not deal breakers to me, seem to be highly sought-after constructs in a modern language. And I'm pretty sure there are other things in the same position.
                spec and standard are different things though. It wouldnt take much for the Rust devs to say "this is the spec for Rust 2020, we shall also abide by it and all api/functional changes will now be a part of the 2021 branch" or something similar. They wont though cause the modern way of doing things is to have one dev team manage the full stack thus allowing everythong to respond to change quicker. Same reason you have to use Cargo and cant effectively build proper support into Meson and CMake

                Comment


                • #9
                  Originally posted by bug77 View Post

                  Hehe, remind me how old was C when it saw its first standardized version? Hopefully, if Rust proves its worth, it won't take as long, but it sure ain't gonna happen anytime soon. I'm not arguing that having a standard helps write a compiler, but standardizing so soon will only cripple development.

                  I mean, imho Rust is nice and everything, but at this point it hasn't pinned down async/await, which, while not deal breakers to me, seem to be highly sought-after constructs in a modern language. And I'm pretty sure there are other things in the same position.
                  Rust has stabilized Async/Await recently, not sure if you mean something else with "pinned down" here tho.

                  I'd say Rust is "there" now, I don't think there are many core language features missing apart maybe for const generics which once done will fix a LOT of inconsistencies and headaches and make the core nice and coherent.

                  Comment


                  • #10
                    It will end the same death as gcj did. Rust is a language that no one uses.

                    Comment

                    Working...
                    X