Announcement

Collapse
No announcement yet.

Rust v10 Patches Posted Ahead Of Expected Merging With Linux 6.1

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

  • #11
    Originally posted by V1tol View Post
    "Syntax sucks" and similar are typical excuses from learning something new. Especially when the language is trying to do the same, sometimes safer and with simpler syntax - and you have invested in C89 for last 40 years lol. Also I don't understand why Rust syntax is considered more ugly than C++ for example. Maybe that is said by people who never did a single line in C, C++ and/or Rust in their lives.
    Tbh, I don't think Rust's syntax is easy on the eye. I mean, if I leave it alone for a couple of months, I have to re-learn what that lifetime voodoo is all about.
    I just don't fault Rust for that - no point, it was a design-time choice that can never be reverted, no matter what arguments you can find against it. I think the goodies behind that syntax are far, far more valuable.

    Comment


    • #12
      Originally posted by bug77 View Post

      Tbh, I don't think Rust's syntax is easy on the eye. I mean, if I leave it alone for a couple of months, I have to re-learn what that lifetime voodoo is all about.
      I just don't fault Rust for that - no point, it was a design-time choice that can never be reverted, no matter what arguments you can find against it. I think the goodies behind that syntax are far, far more valuable.
      I wonder if part of that comes from the convention of using 'a, 'b, etc. as lifetime names. Being part of the method signature or structure definition it couldn't hurt to use more meaningful names. https://www.possiblerust.com/pattern...your-lifetimes wasn't the article I had in mind but it covers a similar sentiment.

      Comment


      • #13
        Originally posted by bug77 View Post

        Tbh, I don't think Rust's syntax is easy on the eye. I mean, if I leave it alone for a couple of months, I have to re-learn what that lifetime voodoo is all about.
        I just don't fault Rust for that - no point, it was a design-time choice that can never be reverted, no matter what arguments you can find against it. I think the goodies behind that syntax are far, far more valuable.
        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.

        Comment


        • #14
          Originally posted by archkde View Post

          Nothing will oxidize, the name comes from a fungus. And yes, LLVM is going to be required, because the GCC frontend is not ready.
          It's like with Python where they use snake-themed icons despite the name coming from Monty Python.

          Originally posted by TheCycoONE View Post

          I wonder if part of that comes from the convention of using 'a, 'b, etc. as lifetime names. Being part of the method signature or structure definition it couldn't hurt to use more meaningful names. https://www.possiblerust.com/pattern...your-lifetimes wasn't the article I had in mind but it covers a similar sentiment.
          ​There's also an off-by-default Clippy lint which'll tell you to use more descriptive names. clippy::single_char_lifetime_names

          Originally posted by jacob View Post

          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 have to disagree. The Ocaml code I look at feels like it "more minorly suffers from" the sense of discomfort and unease I get from Haskell's currying-heavy syntax due to the lack of structure-clarifying punctuation or from something that's trying to be English-esque, like Inform 7. Not an emotional reaction you want to be evoking in the mainstream ecosystem you're trying to break into... but then what do I know. I'm also the person who always put in the parens in paren-optional languages like CoffeeScript when using them.

          Ocaml is also where they did pick up that "Let's use an 'unpaired single quote' to denote a lifetimes" idea that people, including myself, lament. ('a is Ocaml's equivalent to <T>)

          Comment


          • #15
            Originally posted by ssokolow View Post
            Ocaml is also where they did pick up that "Let's use an 'unpaired single quote' to denote a lifetimes" idea that people, including myself, lament. ('a is Ocaml's equivalent to <T>)
            That's true and that's another thing that looks the same but means something totally different from another language. To me the 'a syntax always looks like Scheme ('foo is a symbolic value in Lisp-like languages). Of course this kind of nonsense is not unique to Rust. C++ (or at least the STL) uses the term "traits" for what are essentially mixins. I remember when I learned Haskell how confused I was about their notion of "class". Etc.

            Comment


            • #16
              Originally posted by TheCycoONE View Post

              I wonder if part of that comes from the convention of using 'a, 'b, etc. as lifetime names. Being part of the method signature or structure definition it couldn't hurt to use more meaningful names. https://www.possiblerust.com/pattern...your-lifetimes wasn't the article I had in mind but it covers a similar sentiment.
              Not for me. Me, I just forget where exactly I should put the lifetime.
              I think in my case, it's all those Java years that have trained my brain to look for annotations that usually sit on a different line. And even that is weird, because, really, lifetime declarations are also annotations. They just use single quote where Java uses the at sign.

              Comment


              • #17
                Originally posted by jacob View Post

                That's true and that's another thing that looks the same but means something totally different from another language. To me the 'a syntax always looks like Scheme ('foo is a symbolic value in Lisp-like languages). Of course this kind of nonsense is not unique to Rust. C++ (or at least the STL) uses the term "traits" for what are essentially mixins. I remember when I learned Haskell how confused I was about their notion of "class". Etc.

                Originally posted by bug77 View Post

                Not for me. Me, I just forget where exactly I should put the lifetime.
                I think in my case, it's all those Java years that have trained my brain to look for annotations that usually sit on a different line. And even that is weird, because, really, lifetime declarations are also annotations. They just use single quote where Java uses the at sign.
                It's actually not that crazy on a conceptual level. Lifetimes are a special kind of generic parameter, so you mark them up with Ocaml's generic syntax and put them inside the C++-style generic parameter list.

                I'm just not a fan of syntaxes that hit me like the "easy for computers, hard for humans" reverse of how C needs the Lexer Hack to be parsed. (Even things like Ruby, BASIC, and Bourne shell script, I'm not overly fond of, because using begin/end text rather than punctuation to denote block scopes takes extra work to parse, mentally, since you have to process symbols into words and then distinguish "structural words" vs. "non-structural words" instead of knowing from the simple glyphs themselves.)
                Last edited by ssokolow; 27 September 2022, 07:12 PM.

                Comment


                • #18
                  Originally posted by stefansaraev View Post
                  https://bit.ly/3UMPRHt




                  the thread is worth reading.

                  Michael, there's an issue with long urls
                  I don't think Rust wants you to do away with any of those things. Just get them out of your way, when feasible. E.g. should you have to worry about memory allocation and such when implementing a new sorting algorithm for some queue? Generally, no, you want to concentrate on the business side of things. But if the algorithm requires some funky (specific) memory allocation, you should still be able to do just that.

                  Also, your link is broken, it ends with @mai.

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      Originally posted by rmoog View Post
                      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.
                      That's easy.

                      Programmers are willing to often overlook personal preferences on syntax based on what the language offers to them. For Rust specifically, that would be a systems language with a good ecosystem of tooling and safety features.

                      Comment

                      Working...
                      X