Hacker News Reader

Comment by 0815test | Hacker News Reader

> 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!)

View on HN

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.

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.

Similar to languages much fewer people use, instead of languages more commonly used as systems languages which Rust is meant to be.

In general, it’s a thing more newer languages are moving to, because it’s regarded as superior for a few different reasons. Mostly, it keeps the syntax more regular when you have type inference. See Kotlin as another recent example.

In rust, we have additional reasons, and that’s because it’s not

  let name: type = expression;

It’s

  let pattern: type = expression;

Patterns offer more power than simple variable declarations. The names may not correspond 1-1 with the type, because you can create multiple names by destructuring more complex types

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!

I really like rust, the design is great. I'm glad they cleaned up OOP and ditched nasty C++ stuff like templates.

However, I went through the book recently and I'm quite annoyed that much of the syntax differs needlessly from C like languages. It massively increases the cognitive overhead for someone coming from Java, C++, C#, C-like language world.

Rust is a systems language, it doesn't even have a runtime. 90%+ system level work is done in C-like languages. Rust syntax differs in countless pointless ways. I'm not saying it's wrong, it's just different in ways that don't matter from all other popular systems languages. Which is dumb.

Things like "fn" instead of "function" and async syntax make Rust difficult to adopt by the target user base. Why fn? Is saving 6 characters worth confusing everyone?

> much of the syntax differs needlessly from C like languages. It massively increases the cognitive overhead for someone coming from Java, C++, C#, C-like language world.

And it decreases the cognitive overhead for someone coming from Python, Ruby, Go, heck even Haskell or Ocaml. "Cognitive overhead" over a simpler, more elegant syntax (and I think I've made the case that Rust typing syntax is simpler once you move beyond trivial cases!) is a temporary issue anyway - you get used to it very quickly. What I find quite puzzling here is the particular issue you're complaining about, wrt. the C/C++ type declarations. You actually like having to write out things like "template" and "typename"? Now of course Rust syntax is rather C-like in other ways, but still!

(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;

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.

Exactly, they do stuff like fn yet make it longer than necessary otherwise.

I don't think it should be designed to save keystrokes at the cost of readability.

It already does that elsewhere, yet strange backwards type definitions are much less readable by default to most programmers. It's like making us learn French when we could have learned British English, assuming American English as a starting point.

I think you have to be careful when presuming to speak for "most programmers".

Here, at least 40% of programminging is done in C style syntax. The rest isn't in any consistent majority style. Most programmers are probably most familiar with C style and almost all are familiar in some form.

https://www.tiobe.com/tiobe-index/

I don't think anyone's disputing the claim that "strange backwards type definitions are much less [familiar]". We're saying that familiar is not the same thing as readable(-once-you-know-what-it-is), and that you're talking about the former, not the latter.

Plenty of other languages including a large percent of recent languages have the return type on the right.

Haskell, Visual Basic, Scala, F#, Go, (Rust), Kotlin, TypeScript, Swift.

Even c++ allows you to put return types on the right. Why? Because putting the types on the right allows return type deduction. I think it's better to have a single syntax (all types on the right) rather than 2 syntaxes like c++ has.

https://medium.com/@elizarov/types-are-moving-to-the-right-2...

This is one of the most trivial points I've ever heard for liking or disliking a programming language.

I am not a rust expert, but I assume the recent many programming languages have a keyword for function declaration is so that functions can be first class objects.

It depends... if your return type is nested inside a class and you're defining a member function, you'll have to write down a qualified return type name before the qualified member function name, whereas if the return type follows the function name, it can be unqualified because at that point the class extends the scope used for name lookup.

http://www.stroustrup.com/C++11FAQ.html#suffix-return

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 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++.

Agree. With a dedicated keyword, you can find a function definition using just grep.

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.

C# and Java as you mentioned use very C++-like syntax.

To a first approximation, yes. But consider that the C++ grammar has ~100 more rules than Java (~170 vs. ~280), and parts of the C++ grammar are strongly context-dependent, which isn't true in Java.

Tools can use LLVM infrastructure to get ast. No need to parse it yourself.

The AST is still really complex though (in terms of corner cases to cover).

Reply on news.ycombinator.com