It's worth to remember that C "happened" to stick around because of UNIX, but it's been just another iteration of what started as BCPL; with Go coming from the same people who made Plan 9 (the spiritual successor to Research UNIX) and Alef/Limbo. These guys are equally interested in pushing both PL/OS research and practice.

(I also have no doubt that just like Go fixed C's type declarations, in another 20-30 years, Go's successor will finally fix error handling.)

hence why every recent programming languages are type after name (go included).

I think a proper type system that doesn't special-cases arrays are better, e.g. Array<String>. Pointers may also be part of this uniform structure, e.g. Array<Ref<String>>, and there is zero question on how to parse it even if you are not familiar.

that's the beauty of type after name, it's all left to right, even in special-cases of array, references, and the most confusing-contributor to cdecl: functions `func(int)[5]*string`: perfectly clear, just read left to right.

What about a Map<int, String>?

You can't really encode a tree structure with only linear semantics (without at least something like s-expressions).

And type declarations are s-exprs.

The advantage of type after name is that it keeps the traversing order consistently pre-order (node, left, right), instead of either:

- the notoriously ridiculous spiral cdecl: reading stuff right (output), node (func name) and left (input)

- create a new name to describe the function in pre-order: Func<Input, Output>

But you can't know how many parameters do a user-defined "node" have. I don't see how it can work for generic data structures without a specific syntax for "the children of this node". Go also uses [] for generics, doesn't it?

At that point I find a uniform system (without special-casing arrays and pointers - they are also just types) would be simpler.

I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.

even better, they should have it above or below!

or, declare the type separately, like in fortran or haskell (or in fact, pre-C99 c)

declare the type separately didn't solve the of hard-to-read cdecl problem.

true; but at the same time, any sufficiently complex type is begging to be type-aliased into something more legible/sensible in the first place ... and this is also true for "right-typed" systems.

I've seen julia types unnecessarily fill a whole terminal for otherwise simple operations before, and I have to say I wasn't too impressed...