Hacker News Reader

You do understand that zig started out by removing things from C and then "adding rich constexprs" and that's it? It's arguably simpler than C, C is actually two languages (C and C preprocessor), three if you add make, five if you add cmake and autoconf.

What's the motivation for changing the visually appealing C syntax "ptr->field" to the whack "ptr.*.field"?

ptr.field works.

make, cmake and autoconf are not not part of the C language, they are build tools.

In practice you can't be productive in a large project in C without make, increasingly cmake (at the very least for reading someone else's c project). And it's part of the zig agenda to unify build tools, too. We are now in the 2nd decade of the 21st century, it is not strange for programming languages to be opinionated about build tools, ruby has rake, rust has cargo, js has, well, js is a mess, don't copy js, elixir has mix, etc (and those are just the languages I know).

That doesn’t make those tools part of the C standard, though. The standard does not mandate the use of any particular build tool for C projects beyond a conformant C compiler. There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project. Hell, there is nothing stopping me from using make to build non-C projects - it was designed as a generic dependency resolution tool.

> There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project

There is if you intend to use libraries as those libraries may well have chosen a build system other than the one you have chosen meaning you'd have to rewrite their build scripts. This is far from the experience of using libraries in languages with unified build systems which is typically as simple as adding a line with the version of the library you want to a manifest file.

> That doesn’t make those tools part of the C standard, though

So? I'm talking about the C experience, not the C standard.

You somehow managed to criticize Zig for being something that C isn't, lacking macros, preprocessor and whatnot, and yet praise Go and Python for being opinionated about their features, which don't have preprocessors or macros.

Not really. I praise Python for simple syntax and Go for simplicity of language features.

And I criticize Zig for trying to be another kitchen sink (despite having no macros or preprocessor).

Having few features that are small and knowable is pretty much the idea behind Zig though. It's supposed to be more of a C replacement than another C++/Rust. If you know C you can just read through the Zig language spec and see how stuff correlates and you just learned zig.

Removing a whole secondary language for macros actually just makes the language simpler

Since you like Python's syntax, what's your opinion about Nim?

Honestly, I’m not sure about Nim. I’d probably reach for Go before Nim because I hate layers in-between things and too many language paradigms.

Main thing is that all these hip new languages will be dead in a couple years because they don’t do anything all that innovative. Making “another C” or “another C target” versus Go which focuses on channels, slices, and go routines. These other languages that “make a better X” simply will be sidelined in production deployments because no matter the language there will always be warts.

Really folks keep reinventing the wart in the name of something “better”.

Maybe it's still not the language for you or for your projects, but for anyone else stumbling across this I don't think it's a fair characterization. Would you mind elaborating on where you think I'm off-base in the following?

> head-strong nerds inventing things

Let people have their fun.

> preprocessor allows you to add some logic before compilation

Zig's comptime feature does address that need. For most use cases where comptime and the preprocessor would both suffice, comptime has tons of strong advantages (type checked, errors traced back to the right lines, ability to write arbitrary turing-complete code without unholy syntactic black magic, no double evaluation, no need to wrap everything in extra parentheses, ....). It explicitly does not address use cases where you would actually want a textual preprocessor (like making the language look like Fortran), the argument being that the burden on reading unfamiliar code would be too high. The ease with which you can write arbitrary comptime code also enables you to do things like embed lookup tables in the binary, which in C you would ordinarily do by copy pasting from another tool (or writing constants by hand) or adding yet another preprocessor to the mix.

Comptime isn't a clear win over preprocessing in all cases, but having written a lot of C and a little Zig, if I had to choose one for a hypothetical new project I'd be tempted to use Zig just for access to that one feature.

> Syntax

Zig does feel a little clunky to write to me right now, but I think that's mainly do to how often I'm using @someBuiltin() in Zig when I would be using an operator or an additional language feature in something like Python.

That said, the syntax itself is incredibly simple. You can check that yourself for Zig [0], Python [1], and Go [2]. Zig has far fewer syntactic quirks and abilities than either of the other two. You have functions, operators, code blocks, types, reserved characters/keywords for builtin stuff, a few kinds of literals, and a little bit of syntactic sugar for working with structs.

> Don't reinvent C++...for instance, I even consider C better than Zig just because the features are small and knowable

To each their own. FWIW, Zig is explicitly and actively avoiding becoming a kitchen sink language like Rust or C++. They've added a few new features, and I personally find it easier to keep track of those than of all the different kinds of undefined behavior I might stumble across in C, especially since most of those (defer, errdefer, labeled break, ...) behave exactly as your intuition suggests they would.

[0] https://ziglang.org/documentation/master/#Grammar

[1] https://docs.python.org/3/reference/grammar.html

[2] https://golang.org/ref/spec