I realize I'm stating the obvious, but 'i' is shorter while 'int' is slightly clearer. So I think there's a valid argument for both, but personally I think clarity is more important.
Having said that, less typing and clutter are also beneficial, so it's really a net natural debate.
Clarity is important but I don't see how it suffers from that
except for people reading code in that language for the first
time. To my knowledge the languages shortening this to one
letter are also the kind where the programmer can be expected to
already know the fundamental data types, otherwise this syntax
won't be the biggest problem.
Personally I prefer it, mostly for subjective reasons but I
think it makes sense - in the case of Rust it was the easiest
syntactic novelty to get used to, things like lifetime
annotations are a different beast.
That's a weird strawman. The long names are irrelevant here. It's not about C types overall, just stdint. Each of the languages mentioned uses intN in some form.
When people do something differently than most other popular implementation it's good to ask if that's worth it.
> It existed before. Golang, Haskell, C, D (both kind of - int32_t), caml, and many others. It's i32 that deserves a "why this one?" comment.
"i32" and "u32" are used because they are short (and used often). They are just typedef away in C and are used ~forever, did you look at Linux kernel for example?
But I'm with you on the general sentiment - beyond trivial, lexical things like type names (which almost any language allows you to redefine anyway), Zig appears to have strong NIH mentality in regard to the syntax. Trying to replace C, but go out of their way trying to invent syntax just to be different from it and most other things too.
And a lot of people appear to notice and pay attention to this, as the discussion here shows.
Having said that, less typing and clutter are also beneficial, so it's really a net natural debate.