←back to thread

Open-source Zig book

(www.zigbook.net)
692 points rudedogg | 4 comments | | HN request time: 0s | source
Show context
charlie90 ◴[] No.45950098[source]
>Learning Zig is not just about adding a language to your resume. It is about fundamentally changing how you think about software.

Zig is just C with a marketing push. Most developers already know C.

replies(3): >>45950188 #>>45950368 #>>45951532 #
keyle ◴[] No.45950368[source]
That tagline unfortunately turned me off the book, without even starting to read.

I really don't need this kind of self-enlightenment rubbish.

What if I read the whole book and felt no change?

I think I understand SoA just fine.

replies(1): >>45950420 #
xeonmc ◴[] No.45950420[source]
It is also just such a supremely unziglike thing to state.
replies(1): >>45950587 #
Zambyte ◴[] No.45950587[source]
Early talks by Andrew explicitly leaned into the notion that "software can be perfect", which is a deviation from how most programmers view software development.

Zig also encourages you to "think like a computer" (also an explicit goal stated by Andrew) even more than C does on modern machines, given things like real vectors instead of relying on auto vectorization, the lack of a standard global allocator, and the lack of implicit buffering on standard io functions.

I would definitely put Zig on the list of languages that made me think about programming differently.

replies(2): >>45951107 #>>45951841 #
1. jamiejquinn ◴[] No.45951841[source]
Has it changed how you program in other languages? Because that to me is the true mark of a thought-shifting language.
replies(1): >>45974405 #
2. Zambyte ◴[] No.45974405[source]
The big thing I would say I actually learned and would intentionally apply to other languages is SIMD programming. Otherwise, I'd say it gave me a much clearer mental model of memory management that helps me understand other languages much more fundamentally. Along with getting my hands directly on custom allocators for the first time, a question that took me time to figure out but gave me a lot of clarity in answering was "why can't you do closures in Zig?" Programming in Zig feels very Go-like, and not having closures was actually one of the biggest hiccups for me. I don't think this really changed how I write in other languages, but definitely how I think about other languages.
replies(1): >>45989039 #
3. jamiejquinn ◴[] No.45989039[source]
Snap! I also played around with closures a tonne in Zig. Definitely possible but not... ergonomic. Haven't ended up using them much.

And agree with allocators; in C I always considered using custom allocators but never really needed to. Having them just available in the zig std means I actually use them. The testing allocator is particularly useful IMO.

Never used Go but if it's Zig-like I might give it a shot! Thanks!

replies(1): >>45994341 #
4. Zambyte ◴[] No.45994341{3}[source]
I'll make a list of the things that both languages have in common that make them feel similar to me:

    - structs and functions are the main means of composition
    - the pattern of: allocate resource, immediately defer deallocating the resource
    - errors are values, handled very similarly (multiple return values vs error unions)
    - built in json <-> struct support
    - especially with the 0.16.0 Io changes in Zig, the concurrency story (std.Io.async[0] is equivalent to the go keyword[1], std.Io.Queue[2] is equivalent to channels[3], std.Io.select[4] is equivalent to the select keyword[5])
    - batteries included but not sprawling stdlib
    - git based dependencies
    - built in testing
[0] https://ziglang.org/documentation/master/std/#std.Io.async

[1] https://go.dev/tour/concurrency/1

[2] https://ziglang.org/documentation/master/std/#std.Io.Queue

[3] https://go.dev/tour/concurrency/2

[4] https://ziglang.org/documentation/master/std/#std.Io.select

[5] https://go.dev/tour/concurrency/5