Comment by 0815test

7 years ago

> I thank it for making me a better software engineer

It's especially nice that Rust has kept this basic attitude from C/C++ and in fact strengthened it a lot and aligned it with modern trends, even as it got rid of the annoying "core dumped" part almost in its entirety.

(The latest tagline of Rust is "A language empowering everyone to build reliable and efficient software." Do notice the everyone part, and especially the empowering bit - as opposed to letting even novice developers hobble themselves with substandard, bootcamp-level software-dev practices!)

I wish Rust would have kept saner OOP style classes from C++ instead of this bizarre trait stuff. The whole language feels like everything is just different for the sake of being different. Why is it "fn blah (x -> int.. -> int" or whatever when the rest of the tokens seem designed to save keystrokes at the cost of readability? Everyone is used to "int x(int y..". I've learned it some and the concepts around memory ownership and everything are good but the syntax is needlessly weird and annoying.

  • Special keywords like `fn` make parsing simpler. Trailing return types are useful in languages that support generic programming, because they make it easier to write a function whose return type depends on the types of its generic inputs. Even C++ has this feature now, using decltype and arrow notation:

        template<typename T, typename U>
        auto add(T t, U u) -> decltype(t + u)
        {
            return t + u;
        }
    

    C++ is notoriously hard to parse. Consider the "most vexing parse", or the fact that refactoring tools for C++ are always flakier than their Java / C# / Go equivalents, or the fact that https://cdecl.org/ exists. New languages in the "expressive, high performance" niche cannot continue to be held back by C++ syntax.

  • I actually greatly appreciate that function definitions begin with a dedicated keyword in Rust. I've always found it rather painful that definitions don't stand out from function calls in C and C++.

  • Rust is not based on C++. People coming from Haskell/ML aren't used to C's backwards type declarations, and that's why they're not in Rust; the people who make Rust have experience with more than just C/C++. So it's not different for the sake of being different, it is actually trying to be similar ... just not similar to C.

  • C++ classes vs. Rust traits isn't just a matter of syntax differences.

    Btw the function syntax is:

        fn foo(x: u16, y: u16) -> u32
    

    If it were more C++ like it'd be:

        u32 foo(u16 x, u16 y)
    

    Which is less keystrokes if anything.

    • Amusingly, C++ also supports Rust-style function headers, and has since C++11 (which is well before Rust was ever on the radar; really both C++ and Rust were inspired by ML here). The following two are identical in C++:

          u32 foo(u16 x, u16 y)
          auto foo(u16 x, u16 y) -> u32
      

      IIRC there are contexts where the former does not work and the latter is required, which I believe means that ML-style function headers are strictly more powerful in C++ than the original C-style function headers.

  • I agree. The language design is great, but they purposely use weird conventions everywhere. And by weird, I mean foreign to C++ programmers which is 90% of their user base.

    They should have done what java did. Copy C++ syntax, only change it when needed. I've ported over java code where 2/3 of lines are nearly identical.

    The async debacle is a great example of this. They settled on weird syntax instead of doing what every other language does, because of some holier than thou acedemic snobbery. If every other language does it that way, it would have worked fine in rust.

    • The Rust type syntax is not weird. C-like languages are weird, because their syntax grew by accretion from a much simpler use case where something like "int x;" or even "int f(int a, int b);" could make sense. But even typedefs famously screw that up, never mind everything else.

      > because of some holier than thou acedemic snobbery

      The async syntax was one of the most widely discussed issues in Rust development, and ergonomics concerns were key in what eventually was chosen. It's very misleading to describe it as your comment does.

      Re: parent comment, the Rust programming language book (free online) has a very nice section describing OOP-like patterns in Rust - as it turns out, the "good parts" of OOP are very nicely supported, and in a far simpler, more orthogonal way than what you get in C++. This means fewer dark corners in the language and something far easier to work with overall. Just because it may be different from what we did back in the 1990s, doesn't make it wrong!

      2 replies →

    • (It’s debatable that 90% of our user base is C++ programmers; in 2016, the last time we collected this data, it was 40%, and there’s no reason to believe it’s shifted THAT much since then.)

    • One aspect of this that you might be overlooking is that the syntax for function pointers has to follow the syntax of function declarations.

      Why should a new language inflict this horror on its users:

      let i32 (*foobar)(i32, i32) = add;

      When it can do this instead:

      let foobar: fn(i32, i32) -> i32 = add;