Announcement

Collapse
No announcement yet.

GCC Rust Approved By Steering Committee, Likely To Land For GCC 13

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

  • #21
    There is so much to like about Rust. Cargo is amazing, it comes with a built-in documentation generator. The lib.rs and docs.rs websites that contains documentation for every package. Comes with a package manager. Comes with rustfmt, a code formatter, and it has no options so code style is uniform in the community.

    I love the Option<T> and Result<T> enums. I like the algebraic data type (albeit, with a tuple you don't know what each value represents since it is not named). I love how insanely easy it is define your own custom data types. The borrow checker is an interesting innovation.

    Things I don't like about Rust.
    • The module system is very confusing and awkward. Not intuitive at all.
    • No async functions in traits (Yes, I do know about the third-party macro package)
    • The compiler is slow.
    • There no easy way to check for package updates or update the packages. In the JavaScript world, npm has npm outdated which is nice.
    • For lambdas I would much prefer x => y(x) as syntax over |x| y(x) used by Rust and Ruby.

    Comment


    • #22
      Originally posted by uid313 View Post
      There is so much to like about Rust. Cargo is amazing, it comes with a built-in documentation generator. The lib.rs and docs.rs websites that contains documentation for every package. Comes with a package manager. Comes with rustfmt, a code formatter, and it has no options so code style is uniform in the community.

      I love the Option<T> and Result<T> enums. I like the algebraic data type (albeit, with a tuple you don't know what each value represents since it is not named). I love how insanely easy it is define your own custom data types. The borrow checker is an interesting innovation.

      Things I don't like about Rust.
      • The module system is very confusing and awkward. Not intuitive at all.
      • No async functions in traits (Yes, I do know about the third-party macro package)
      • The compiler is slow.
      • There no easy way to check for package updates or update the packages. In the JavaScript world, npm has npm outdated which is nice.
      • For lambdas I would much prefer x => y(x) as syntax over |x| y(x) used by Rust and Ruby.
      What do you mean with rustfmt has no options?
      https://rust-lang.github.io/rustfmt
      btw the idea of having a uniform code style across a whole language is asinine at best.
      Of course projects should have uniform styles, but enforcing 1 true style for some alleged ecosystem benefit makes no sense to me.
      If only because if I can't bring myself to like this one true style I'll just avoid using this formatter, defeating its purpose.
      eg: I can't work with 2 space indentation. If indentation size can't be configured (dartfmt sucks) I'll avoid the formatter and won't allow it near any code I'm managing...

      Comment


      • #23
        Originally posted by mdedetrich View Post

        Or you could just do your research and stop spreading BS.

        Linux used many non standard GCC extensions in the codebase which meant that only GCC could compile it, it wasn't a standard C codebase in this regard (so much for standards).
        So I did a bit of research, and although there were issues with nonstandard GCC extensions, it appears that the majority of the issues were due to different design decisions between the two projects. Clearly it did not have to take nearly 20 years to build kernels with llvm, in fact with a little push-through it appears it should have been done by 2015. But, whatever, everyone's got their own priorities.

        Comment


        • #24
          Updated Tool Chain Contempt (UTCC)

          C++ -> C -> Rust -> [Pascal] -> Java -> [Perl] -> Python -> [Ruby] -> ... -> PHP

          [..] denotes dead or dying languages.

          Constant for almost two decades: C++ is at the top, PHP is at the bottom.

          Comment


          • #25
            Originally posted by domih View Post
            Updated Tool Chain Contempt (UTCC)

            C++ -> C -> Rust -> [Pascal] -> Java -> [Perl] -> Python -> [Ruby] -> ... -> PHP

            [..] denotes dead or dying languages.

            Constant for almost two decades: C++ is at the top, PHP is at the bottom.
            C/C++ toolchain? I thought C/C++ were more of a suggestion for compilers to implement their own language with. Doesn't even the standard specs say that? Just look at GCC C and MSVC C, they're basically different languages.
            Oh and then you have build systems. All of the build systems.

            Comment


            • #26
              Originally posted by uid313 View Post
              Comes with rustfmt, a code formatter, and it has no options so code style is uniform in the community.
              Huh. I didn't realize I was imagining the effects of putting use_small_heuristics = "Max" in rustfmt.toml to optimize for reading my code on non-portrait-oriented monitors.

              I love the Option<T> and Result<T> enums. I like the algebraic data type (albeit, with a tuple you don't know what each value represents since it is not named). I love how insanely easy it is define your own custom data types. The borrow checker is an interesting innovation.

              Originally posted by uid313 View Post
              Things I don't like about Rust.
              • The module system is very confusing and awkward. Not intuitive at all.
              • No async functions in traits (Yes, I do know about the third-party macro package)
              • The compiler is slow.
              • There no easy way to check for package updates or update the packages. In the JavaScript world, npm has npm outdated which is nice.
              • For lambdas I would much prefer x => y(x) as syntax over |x| y(x) used by Rust and Ruby.
              If it helps, you can think of mod as mount and use as ln -s.

              They're working on the async functions in traits thing but, given the constraints of the stability promise, they have to get it right the first time if they put it into the compiler itself, so you may want to subscribe to updates on the stabilization of GATs as the basis for doing it.

              For checking for package updates, the number-one third-party Cargo plugin is cargo-outdated, there's a built-in cargo update for updating Cargo.lock in a non-semver-breaking way, and cargo-edit (from which cargo add recently got merged into mainline Cargo) provides cargo upgrade for semver-breaking updates to Cargo.toml.

              Comment


              • #27
                Originally posted by Developer12 View Post

                Rust doesn't need to get picked up by GCC to get into linux (Torvalds said himself that Rust might get picked up next kernel cycle).

                However, Rust does need GCC support to be used for non-optional core Linux kernel stuff. You can't replace part of the memory management with Rust without GCC support, because then a significant number of architectures supported by linux wouldn't be able to compile the kernel. You would effectively be dropping support for them.
                Or you could port LLVM to these architectures, which might turn out to me be less effort and have more benefit in the end.

                Comment


                • #28
                  Originally posted by babali View Post
                  What's the benefit of having a GCC port?
                  way more platforms supported, is one i can think of. also might be easier to bootstrap on atypical architecture.

                  Comment


                  • #29
                    Originally posted by uid313 View Post
                    The module system is very confusing and awkward. Not intuitive at all.
                    Interesting, could you elaborate more? I find the module system completely intuitive, but that might also be due to already having learned about its warts from OCaml.

                    There no easy way to check for package updates or update the packages. In the JavaScript world, npm has npm outdated which is nice.
                    cargo upgrade --dry-run

                    The compiler is slow.
                    Yeah, it is, just like the C++ compilen. Fortunately, there is "cargo check" which you can use to check your code for errors, it basically tells the compiler to stop right before the (slow) code generation.

                    For lambdas I would much prefer x => y(x) as syntax over |x| y(x) used by Rust and Ruby.
                    I agree here, but it's not the end of the world either.

                    Comment


                    • #30
                      Originally posted by uid313 View Post
                      • There no easy way to check for package updates or update the packages. In the JavaScript world, npm has npm outdated which is nice.
                      I usually just use "cargo update" for minor and patch upgrades, and deps.rs for majors and CVE issues. Works fine.

                      Comment

                      Working...
                      X