Are core dumps per se, really bad? I think, that the feature is useful. What is bad is frequency of it happening. For example: are Python's tracebacks better? Maybe I had a bad luck, but in my experience they happen with similar frequency. Core dumps allow you to go to debugger and see what has happened. You can easily send the file. If the crashed software goes without source you can't do a thing, but that's what was the intention. With obfuscated Python one would also be left with nothing.

I speculate the parent comment was referring to the frequency of core dumps: that he/she experiences more of them compared to the Python tracebacks you mentioned.

Disclaimer, I'm speculating that's what they meant, because I feel the same way. It's more common(for me) for Python to refuse to run than to run anyway and later crash, compared to C++. That said, Python isn't a good analogy there...Rust or Golang are more likely to refuse to run for bad code instead of running anyway and crashing later.

Core dumps aren't bad themselves. But the ease and frequency by which other developers (and myself) can cause a core is just insane. It makes C++ more of a headache than anything.

I know; I prefer the ITS/Lispm environment in which you were always running in the debugger. But I think most users wouldn't like that. Bill Gates laughed at me when I once suggested it in passing.

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.

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

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.

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.

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.

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

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.

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.

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

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.

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

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.

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

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!

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