Zig, the Ideal C Replacement Or?

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic.

And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an example)

Verbosity is mostly subjective. Most of Author's concerns were path lengths, which can easily be "fixed" by redefining the path into a constant. `const debug = std.debug;` I also think the Argument towards "it looks like java's println" full on is a bad argument. Especially because `std.debug.print` does something completely different.

The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it.

Then half of the arguments about comptime i also don't quite understand. It seems like it is building up the main point of the argument, but then you just get hit by a statement. So no explanation no nothing. Talking about lazy evaluation and a little bit of how SoA makes things worse (which i have no clue how that matters in this context) and then saying it's violation "no hidden control flow" is not really getting the point i feel like.

I've been closely following and evaluating the train of C replacement languages that was (I believe) started by Jonathan Blow and Jai.

Zig is one of the strong contenders, but Odin is IMO following a saner path, Carbon and D should be mentioned and I think there are a few others.

My initial reaction to new programming languages is naturally skeptical, but I really liked the way the designers behind those efforts approached it, trying to solve frequent C/C++ pain points and adding a few fresh ideas.

But overall, after a few years, I am sticking with C and orthodox C++, the cost/benefit ratio is simply not worth the effort, none of them are really mature and the problems they try to solve are not painful enough.

My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings.

An other analogy that can be made is the many attempts at replacing keyboards layouts. Dvorak etc. They probably have their merits, but the adoption was limited to a few enthusiasts for the same reasons that C is unlikely to get replaced by any of those forks.

> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const.

This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn the language. I get the rationale, that it's trying to protect me from shipping poorly designed code. But helicopter mom features do not belong in a programming language. They are just as hindering to progress as a literal one would be to a grown man, and for the exact same reasons. I know Andrew has made up his mind, but minds can be changed. So please, Andrew, please take away this helicopter mom feature.

    _ = my_unused_variable;

I think the author's criticism of the named initializer requirement is emblematic of a big problem I have with most new languages. The author says that it makes things like vectors more verbose and awkward, which is true.

My counter to this is: who gives a shit? I'm not writing a vector library or a game engine; I'm writing systems code, and unnamed initializers are harder to read and expose code to subtle bugs. And for what? So that vectors look prettier?

A lot of programming language design seems to prioritize making its own standard library math functions more elegant to implement, which I find to be very irritating, and Zig is a breath of fresh air in this regard.

C is not going anywhere. Neither are C++, Java, and JS (less sure about TS).

One reason is that we've built most of the foundations of modern software already in these languages. New apps pop up all the time but they all rely on ffmpeg, etc.

The only way for a new language like Zig to cement itself is to build foundational software that other programs depend on. I don't think even Rust is moving in that direction (lots of Rust apps, but not so many libs I've had to use in my programs that were written in Rust).

Discussion yesterday of Odin, that touched on Zig and D.

https://news.ycombinator.com/item?id=43939520

Previous discussion (9 comments, 2 days ago): https://news.ycombinator.com/item?id=43942094

Some fair criticisms of differing importance, but the tone of the article feels pretty off putting. Almost like the author has some personal gripe against someone affiliated with Zig something.

Back when it still had async support, I looked at using Zig in QEMU.

My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement.

Having to know the full set of Zig sources in advance due to error types, and the strong accent on Zig as a build system, are both a non starter for integration in existing large C programs, for example.

    %.o: %.zig
        zig build-obj *.zig -o *.o

The author hand waves away ReleaseSafe, but does not really seem to understand its usage.

I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Since zig allows turning off/on safety checks on a per-block basis, you only need to pay as much of a performance cost as you want for this.

Actually, this doesn't really come across as a sincere critique of zig. It's more like how a sport fan talks about a rival team (I guess the author must be team Odin). The "first impressions" section is silly.. of course you don't understand how it all works before you've learned anything about it. It might be a bit confusing and have some new patterns. And yes, all the options of the advanced build system is complex, but... you can use the simple build mechanism, or just go with the template for that matter.

Myself, I think there are certainly valid criticisms of zig to make and I don't know if it's ultimately going to amount to something, but you've got to have some knowledge of the subject and not come at it with a predetermined conclusion.

Its always interesting to me that other people have such an issue with languages being verbose. I have never really understood why people feel this way. It's just a bit of extra typing. I also think it generally increases code readability. Anyone who dislikes verbose languages care to explain their perspective to me?

zig ld should be the only cross-linker out there, and I'm considering migrating to zig, for zig ld's sake .

All programming languages that claim to be alternatives to C eventually become themselves, zig is good enough and different enough to not care about being an alternative to C!

That would have been Modula-2 already in 1978, but sadly Acorn, yes the one from ARM, was the only OS vendor adopting it.

The worst part IMO is no decent LSP like rust-analyzer.

Does it run on Arduino?

Because we rarely have objective measures by which to compare programming languages, there is no such thing as "ideal." Some objective measures can include code size, and it is undoubtedly true that switching from Assembly to Python often results in a super-linear reduction in code size, but we rarely see such differences anymore. When we do get some objective comparisons through empirical research -- always many years later -- we also find that usually differences between languages are smaller than many would expect [1]. This isn't surprising and, in fact, it was predicted by Fred Brooks in the 80s. This is because much of the difficulty in constructing algorithms is essential. This is not just due to results in computational complexity about the fundamental difficulty in constructing and analysing programs, but also part of computers' utility. As I once heard a NASA developer say, "computers were built to surprise us; if we knew their output we wouldn't need to build them."

That's a long-winded way of saying that programming language preference is mostly a matter of personal taste as well as more objective but non-intrinsic, "environmental" or social factors. But that doesn't mean that preferences are evenly distributed. Even within a specific domain there may be big disagreements among programmers over which language is "better," but some languages may appeal to significantly more people than others. Programming language designers, at least those who target their language for wide audiences, effectively try to pick tradeoffs that they guess would appeal to many.

This is what makes statements like "but as we all know, it’s not always the best alternative that wins" meaningless. Winning means appealing to more people, i.e. having a good "market fit", whereas "best" has no agreed-upon definition. Like in the famous story about Betamax vs VHS, one had a better picture quality at the expense of recording time, and it turned out that a longer recording time was more important to them than better picture quality. In various debates over programming languages, I often see people frustrated when confronted with the reality that other people prefer different tradeoffs to their own preferred ones.

What the author find surprising or confusing in Zig are things others find desirable (for reasons such as making the language more expressive, simpler, more easily portable, or faster to compile). If you prefer Odin or Rust or Jai -- use them; that different people prefer different languages is very much to be expected. But one of the things I, subjectively, find appealing in Zig has to do with the point made in the post about "high level conveniences" and "abtractions." Over the past several decades, high-level languages have become so fast that in most software it makes little sense to use low-level languages regardless of the "high level conveniences" they may offer. But low-level languages still have a very important role to play when full control over resource usage (especially memory) is needed, such as in constrained environments. That is why I, as someone who does both high and low-level programming, prefer a separation between the two. I probably won't write a large, complex application in any low-level language, and when I do write low-level code, what's important to me is to clearly see what's going on. Anything that hides that from me isn't a convenience but an inconvenience when doing this kind of programming. To me, subjectively, it seems that making low-level languages appear more high level is a mistake -- it hinders low-level programming without offering a truly compelling alternative to a high-level language. Whether my preferences or the author's are more common is something we'll find out in another decade or so.

[1]: One of the things I find annoying -- not only in programming language debates but in science and technology discourse in general -- is invalid extrapolation of valid empirical results. For example, we do have some valid empirical comparisons of TypeScript vs JavaScript or Rust vs. C, but extrapolating from those to conclusions about, say, TypeScript vs. Clojure or Rust vs. Zig requires making unfounded (as yet) assumptions (such as that all untyped languages are alike or that all languages that don't soundly prevent all undefined behaviour are alike).

The message I got upon connecting to this site:

> Website Access Prohibited

> Malware Website Warning

> The website you are trying to access is known to host malware and poses a security risk to your computer and network. Please contact your IT help desk to review if you are impacted. If you think you are receiving this message in error, please contact your IT help desk.

I guess you should know your website is seen as a malware vector.