Languages have many competing goals. It shouldn't take long to get used to u64 over, e.g., unsigned_int64, and brevity is valuable in its own right. Too many wasted characters can obscure the flow of a program and make it slower to read and understand.
Is it the right choice? I could be persuaded either way. I know it's one I've personally made before, choosing rebindings like i256 and cmpeq8 when doing a lot of bit-twiddly vector code.
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.
Syntax has a heavy influence on function, so if all languages had very similar syntax, they couldn't be ideologically diverse without jumping through ridiculous hoops.
> couldn't be ideologically diverse without jumping through ridiculous hoops.
Jumping thru hoops is what Zig seems to choose with its unorthodox, different-just-to-be-different syntax. I wonder, how many will want to jump with it?
> Jumping thru hoops is what Zig seems to choose with its unorthodox, different-just-to-be-different syntax.
Did zig run over your dog or something? You seem to be particularly hostile in your comments about it. As someone who has participated in discussions about zig syntax for years, I can assure you that a significant amount of thought and consideration goes into these choices. It is not "different-just-to-be-different". In fact, the very syntax being complained about is derived from other languages!
No, I'm adept of (anti)survivorship bias. In other words, I like to study mistakes. And Zig offers a great field of study in that regard, as many issues are seen with a naked eye (i.e. even to casual passers-by).
Why its not int64, int32, unsigned_int32, vec, function for all language, but inventors have to change these to u64, i64, fn...etc?