JS, C++, C# are what I'm coming from. There was no need to put things in strange orders and otherwise do so many other things different from C style for no apparent reason. Sure, you can find some example of another language doing something any way, but that doesn't make it a good idea. What tangible benefit is there to having to put the type after the function declaration?

You've given one concrete example, the type after the function deceleration.

I'll respond to that because there is a concrete benefit. For what it's worth, typescript, go, SML, haskell, and many other languages follow this pattern too.

In C, there's the "clockwise spiral rule"[0] to read a complex c declaration. Let's take an example from that:

    void (*signal(int, void (*fp)(int)))(int);

In rust, that would be:

     fn signal(i: isize, fp: Fn(isize) -> ()) -> Fn(isize) -> ()

In rust, the clockwise spiral rule is more simply the "read left to right" rule, which follows more naturally for most people.

For what it's worth, C++ also includes alternate function syntax [1], which matches rust's ordering of return values.

The reason it was added to C++ is because there were actual expressions the old syntax could not unambiguously express. Even to a machine the C-style declaration is more confusing.

With no offence meant, you're sounding a little blub[2]-ish in that complaint.

[0]: http://c-faq.com/decl/spiral.anderson.html

[1]: https://en.wikipedia.org/wiki/C++11#Alternative_function_syn...

[2]: http://www.paulgraham.com/avg.html

The spiral rule is wrong (or at least overcomplicated). There was once a guy who didn't understand how C declarations work, so he made some guesses, put them on his webpage, and then he still didn't know how declarations work! Too bad this page got so popular.

What he did was essentially he discovered precedence rules for normal C expressions. That's all. https://news.ycombinator.com/item?id=22451431

While you are correct that the spiral rule is an over-complicated (and sadly, popular) rule for C declarations, that doesn't really answer GP's point -- that putting the types after the binding results in much less messy type signatures. This was the reason why Go went with such a setup (and presumably also Python, though their hand was slightly forced by backwards compatibility concerns).

Consider it a reaction to something else than what might be the true point of this comment. Nothing wrong about that.

And that point is pretty much a straw man, intentionally cherry-picked and obfuscated. The type signature in my signal(3) manpage is given as

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

And functions taking and returning function pointers are exceedingly rare. In practice I still find C type syntax the easiest to read (it's so concise, and in fact there is almost no type synax because it's just expressions). The valid argument for me why we should move away from that syntax is tooling - the syntax is hard to parse for machines (but not for humans) because it requires serial reading and complete preprocessing from the start of the file.

That's like insisting Month/Day/Year is the one true way to write dates, and thus having a hard time ever spending time outside the USA.

Actually, the C, C++, Java, C# dynasty being the USA of programming languages seems quite fitting in terms of economics.