[bscphil]

> Like Rust, Zig uses 'name' (':' Type)? syntax for ascribing types, which is better than Type 'name'

I'm definitely an outlier on this given the direction all syntactically C-like new languages have taken, but I have the opposite preference. I find that the most common reason I go back to check a variable declaration is to determine the type of the variable, and the harder it is to visually find that, the more annoyed I'm going to be. In particular, with statically typed languages, my mental model tends to be "this is an int" rather than "this is a variable that happens to have the type 'int'".

In Rust, in particular, this leads to some awkward syntactic verbosity, because mutable variables are declared with `let mut`, meaning that `let` is used in every declaration. In C or C++ the type would take the place of that unnecessary `let`. And even C (as of C23) will do type inference with the `auto` keyword. My tendency is to use optional type inference in places where needing to know the type isn't important to understand the code, and to specify the type when it would serve as helpful commentary when reading it back.

[SkiFire13]

> In C or C++ the type would take the place of that unnecessary `let`

In my opinion the `let` is not so unnecessary. It clearly marks a statement that declares a variable, as opposed to other kind of statements, for example a function call.

This is also why C++ need the "most vexing parse" ambiguity resolution.

[reactordev]

I’m in the same boat. It’s faster mentally to grok the type of something when it comes first. The name of the thing is less important (but still important!) than the type of the thing and so I prefer types to come before names.

From a parser perspective, it’s easier to go name first so you can add it to the AST and pass it off to the type determiner to finish the declaration. So I get it. In typescript I believe it’s this way so parsers can just drop types all together to make it compatible with JavaScript (it’s still trivial to strip typing, though why would you?) without transpiling.

In go, well, you have even more crazier conventions. Uppercase vs lowercase public vs private, no inheritance, a gc that shuns away performance minded devs.

In the end, I just want a working std library that’s easy to use so I can build applications. I don’t care for:

    type Add<A extends number, B extends number> = [
      …Array<A>,
      …Array<B>,
    ][“length”]

This is the kind of abuse of the type system that drives me bonkers. You don’t have to be clever, just export a function. I don’t need a type to represent every state, I need intent.

[AnimalMuppet]

I, too, go back up the code to find the type of a variable. But I see the opposite problem: if the type is first, then it becomes harder to find the line that declares the variable I'm interested in, because the variable name isn't first. It's after the type, and the type could be "int" or it could be "struct Frobnosticator". That is, the variable name is after a variable-length type, so I have to keep bouncing left to right to find the start of the variable name.

[Quekid5]

> I find that the most common reason I go back to check a variable declaration is to determine the type of the variable,

Hover the mouse cursor over it. Any reasonable editor will show the type.

> In Rust, in particular, this leads to some awkward syntactic verbosity, because mutable variables are declared with `let mut`, meaning that `let` is used in every declaration.

Rust is very verbose for strange implementation reasons... namely to avoid parse ambiguities.

> In C or C++ the type would take the place of that unnecessary `let`.

OTOH, that means you can't reliably grep for declarations of a variable/function called "foo". Also consider why some people like using

    auto foo(int blah) -> bool

style. This was introduced because of template nonsense (how to declare a return type before the type parameters were known), but it makes a lot of sense and makes code more greppable. Generic type parameters make putting the return type at the front very weird -- reading order wise.

Anyhoo...

[bscphil]

>> I find that the most common reason I go back to check a variable declaration is to determine the type of the variable,

> Hover the mouse cursor over it. Any reasonable editor will show the type.

That applies to most of us, obviously, but in this context we're talking about Zig. Zig's lead developer, Andrew Kelley, programs in Vim with no autocomplete or mouse support.

Even though I sometimes use editors with these features, I find it frustrating when languages seem to be designed in such a way that presumes their availability. I found Rust particularly bad about this, for example.

[MoltenMan]

I much prefer Pascal typing because it

1. Allows type inference without a hacky 'auto' workaround like c++ and 2. Is less ambiguous parsing wise. I.e. when you read 'MyClass x', MyClass could be a variable (in which case this is an error) or a type; it's impossible to know without context!

[erk__]

Maybe it just have to do with what you are used to, it was one of the things that made me like Rust coming from F# it had the same `name : type` and `let mutable name` that I knew from there.