Comment by poly2it
3 months ago
> Learning Zig is not just about adding a language to your resume. It is about fundamentally changing how you think about software.
I'm not sure what they expect, but to me Zig looks very much like C with a modern standard lib and slightly different syntax. This isn't groundbreaking, not a thought paradigm which should be that novel to most system engineers like for example OCaml could be. Stuff like this alienates people who want a technical justification for the use of a language.
There is nothing new under the Sun. However, some languages manifest as good rewrites of older languages. Rust is that for C++. Zig is that for C.
Rust is the small, beautiful language hiding inside of Modern C++. Ownership isn't new. It's the core tenet of RAII. Rust just pulls it out of the backwards-compatible kitchen sink and builds it into the type system. Rust is worth learning just so that you can fully experience that lens of software development.
Zig is Modern C development encapsulated in a new language. Most importantly, it dodges Rust and C++'s biggest mistake, not passing allocators into containers and functions. All realtime development has to rewrite their entire standard libraries, like with the EASTL.
On top of the great standard library design, you get comptime, native build scripts, (err)defer, error sets, builtin simd, and tons of other small but important ideas. It's just a really good language that knows exactly what it is and who its audience is.
I think that describing Zig as a "rewrite of C" (good or otherwise) is as helpful as describing Python as a rewrite of Fortran. Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. That makes the similarities to C rather superficial. After all, Zig is as expressive as C++.
> Most importantly, it dodges Rust and C++'s biggest mistake, not passing allocators into containers and functions
I think that is just a symptom of a broader mistake made by C++ and shared by Rust, which is a belief (that was, perhaps, reasonable in the eighties) that we could and should have a language that's good for both low-level and high-level programming, and that resulted in compromises that disappoint both goals.
To me, the fact that Zig has spent so long in development disqualifies it as being a "rewrite of C."
To be clear, I really like Zig. But C is also a relatively simple language to both understand and implement because it doesn't have many features, and the features it does have aren't overly clever. Zig is a pretty easy language to learn, but the presence of comptime ratchets up the implementation difficulty significantly.
A true C successor might be something like Odin. I am admittedly not as tuned into the Odin language as I am Zig, but I get the impression that despite being started six months after Zig, the language is mostly fully implemented as envisioned, and most of the work is now spent polishing the compiler and building out the standard library, tooling and package ecosystem.
3 replies →
> Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection.
To my understanding (and I still haven’t used Zig) the “comptime” inherently (for sufficiently complex cases) leads to library code that needs to be actively tested for potential client use since the instantiation might fail. Which is not the case for the strict subset of “compile time” functionality that Java generics and whatnot bring.
I don’t want that in any “the new X” language. Maybe for experimental languages. But not for Rust or Zig or any other that tries to improve on the mainstream (of whatever nice) status quo.
3 replies →
I don't know man, Rust's borrowing semantics are pretty new under the sun, and actually do change the way you think about software. It's a pretty momentous paradigm shift.
Zig is nice too, but it's not that.
To call Rust syntax beautiful is a stretch. It seems that way in the beginning but then quickly devolves into a monstrosity when you start doing more complex things.
Zig on the other specifically addresses syntax shortcomings in part of C. And it does it well. That claim of rust making C more safe because it’s more readable applies to Zig more than it does to Rust.
I feel like the reason the rust zealots lobby like crazy to embed rust everywhere is twofold. One is that they genuinely believe in it and the other is that they know that if other languages that address one of the main rust claims without all the cruft gains popularity they lose the chance of being permanently embdedded in places like the kernel. Because once they’re in it’s a decade long job market
34 replies →
Kind of, https://en.wikipedia.org/wiki/Cyclone_(programming_language)
What it has achieved is making affine types something mainstream developers would care about.
3 replies →
There were languages with lifetimes and borrowing mechanics before Rust. Rust packages these mechanics in a nice way. Just like Zig encodes many niceties in a useful C language (comptime, simple cross-compilation, stdlib).
4 replies →
> actually do change the way you think about software. It's a pretty momentous paradigm shift.
That's true for people who doesn't read and think about the code they write. For people who think from the perspective of a computer, Rust is "same checks, but forced by the compiler".
Make no mistake, to err is human, but Rust doesn't excite me that much.
> Most importantly, it dodges Rust and C++'s biggest mistake, not passing allocators into containers and functions
Funny. This was a great sell to me. I wonder why it isn’t the blurb. Maybe it isn’t a great sell to others.
The problem for me with so many of these languages is that they’re always eager to teach you how to write a loop when I couldn’t care less and would rather see the juice.
However, nowadays with comprehensive books like this, LLM tools can better produce good results for me as I try it out.
Thank you.
Very, very few people outside of foundational system software, HFT shops, and game studios understand why it's a great selling point. Everyone else likes the other points and don't realize the actual selling point of the language.
>Rust is that for C++
No it's not. Rust has roots in functional languages. It is completely orthoganol to C++.
Graydon Hoare, a former C++ programmer on Mozilla Firefox and the original creator of Rust, acknowledges that for many people, Rust has become a viable alternative to C++ :
https://graydon2.dreamwidth.org/307291.html
And on slide #4, he mentions that "C++ is well past expiration date" :
https://venge.net/graydon/talks/intro-talk-2.pdf
It's possible that Graydon's earliest private versions of Rust the 4 years prior to that pdf were an OCaml-inspired language but it's clear that once the team of C++ programmers at Mozilla started adding their influences, they wanted it to be a cleaner version of C++. That's also how the rest of the industry views it.
2 replies →
> Rust and C++'s biggest mistake, not passing allocators into containers and functions
Rather, basing its entire personality around this philosophy is Zig's biggest mistake. If you want to pass around allocators in C++ or Rust, you can just go ahead and do that. But the reason people don't isn't because it's impossible in those languages, it's because the overwhelming majority of the time it's a lot of ceremony for no benefit.
Like, surely people see that in C itself there's nothing stopping anyone from passing around allocators, and yet almost nobody ever does. Ever wonder why that is?
Much of the book's copy appears to have been written by AI (despite the foreword statement that none of it was), which explains the hokey overenthusiasm and exaggerations.
As we know AI is at least as smart as the average human. It knows the Zeitgeist and thus adds “No AI used” in order to boost “credibility”. :) (“credibility” since AI is at least as smart the average human, for us in the know.)
That's ok, in the near future nobody will actually read this book. AI will be reading it. This is training data.
For those who actually want to learn languages which are "fundamentally changing how you think about software", I'd recommend the Lisp family and APL family.
I'd also throw Erlang/Elixir out there. And I really wished Elm wasn't such a trainwreck of a project...
What is the most optimal Erlang/Elixir you can think of regarding standardized effect systems for recording non-determinism, replaying and reversible computing? How comparable are performance numbers of Erlang/Elixir with Java and wasm?
1 reply →
No need to include Elixir here; none of the important bits that will change how you view software come from Elixir, it's just a skin on top of Erlang (+ some standard library wrappers) and that's it.
5 replies →
And Prolog as well.
And Forth.
And 6502 assembly. ;)
And SNOBOL.
And Icon.
And ...
Am I correct that you can essentially "learn APL without learning APL" by just learning Numpy / Pytorch?
I looked at array languages briefly, and my impression was that"ooh this is just Numpy but weirder."
Not even close. While Numpy has many similar operations, it lacks the terseness, concepts like trains and forks etc. Modern APL style doesn't use... control flow (neither recursion nor loops nor if...) and often avoids variables (tacit/point-free style).
You might enjoy this video: https://www.youtube.com/watch?v=a9xAKttWgP4
Zig is so novel that it's hard to find any language like it. Its similarity to C is superficial. AFAIK, it is the first language ever to rely on partial evaluation so extensively. Of course, partial evaluation itself is not new at all, but neither were touchscreens when the iPhone came out. The point wasn't that it had a touchscreen, but that it had almost nothing but. The manner and extent of Zig's use of partial evaluation are unprecedented. I have nothing against OCaml, but it is a variant of ML, a 1970s language, that many undergrads were taught at university in the nineties.
I'm not saying everyone should like Zig, but its design is revolutionary:
https://news.ycombinator.com/item?id=45852774
I guess comptime is a little different but yeah I wouldn't say it fundamentally changes how you think about software.
I wouldn't say that about OCaml either really though. It's not wildly different in the way that e.g. Lean's type system, or Rust's borrow checker or Haskell's purity is.
D has similar comptime capabilities if I recall correctly and proceeds Zig by almost 2 decades or so.
I don't think it's the same. You can do template metaprogramming, but Zig lets you use Zig itself which is a lot nicer.
I'm not a D programmer though so I could be wrong.
1 reply →
> It is about fundamentally changing how you think about software.
> I'm not sure what they expect, but to me Zig looks very much like C
Yes. I think people should sincerely stop with this kind of wording.
That makes Zig looks like some kind of cult.
Technically speaking, Zig democratized the concept of imperative compile time meta-programming (which is an excellent thing).
For everything else, this is mainly reuse and cherry pick from other languages.
Zig community really tries to match Rust one in terms of cult resemblance.
Did it occur to you that Rust and Zig might actually be very good?
Oh, they are. Like a multitude of other languages.
2 replies →
People that consider other people that are excited about something "culty" are usually people that themselves are excited by absolutely nothing.
That's a very profound statement! Logical and sounds intelligent. Nice one!
PS: I'm stealing it, by the way.
Nicely formulated, yet not less empty than the picture you try to sketch.