4 ms·
These are extremely trivial, to the point that I don’t really know what you’re complaining about. What would expect or prefer?
by dwb 11mo ago
These are extremely trivial, to the point that I don’t really know what you’re complaining about. What would expect or prefer?
- kachapopopow 11mo agoit's not about triviality, but why not use what is generally accepted already, why did zig decide to be different?
- int_19h 11mo agoWhat is "generally accepted" though? If you mean C-style declarations, the fact that tools such as https://linux.die.net/man/1/cdecl https://linux.die.net/man/1/cdecl even exist to begin with shows what's wrong with it.
- kachapopopow 11mo ago<auto/type/name> <name/type> (array?) (:)= (value) <fn> <generic> <name>(<type/argument>[:] <type/argument> [(->/:) type] [import/use/using] (<package>[/|:|::|.]<type> | "file") (ok header files are a relic of the past I have to admit that) I tried writing zig and as someone who has pretty much written in every commonly used language it just felt different enough where I kept having to look up the syntax.
- dwb 10mo agoThere’s almost countless languages that don’t do anything like this, whereas Zig is very similar. It’s fine to prefer this syntax or that, but Zig is pretty ordinary, as languages go. So yes, the differences are trivial enough that it’s a bit much to complain about. You can’t have spent much time with Zig or you’d have learned the syntax easily.
- gf000 11mo agoThe same goes for go, though. And out of the two, I find Zig is still closer to any sane existing language schema. While go is like, let's write C-style types, but reverse the order, even though there is a widely accepted type notation that already reverses it with a :, that even let's you infer types in a sane way.