Open-source Zig book

I think it mostly comes down to the standard library guiding you down this path explicitly. The C stdlib is quite outdated and is full of bad design that affects both performance and ergonomics. It certainly doesn't guide you down the path of smart design.

Zig _the language_ barely does any of the heavy lifting on this front. The allocator and io stories are both just stdlib interfaces. Really the language just exists to facilitate the great toolchain and stdlib. From my experience the stdlib seems to make all the right choices, and the only time it doesn't is when the API was quickly created to get things working, but hasn't been revisited since.

A great case study of the stdlib being almost perfect is SinglyLinkedList [1]. Many other languages implement it as a container, but Zig has opted to implement it as an intrusively embedded element. This might confuse a beginner who would expect SinglyLinkedList(T) instead, but it has implications surrounding allocation and it turns out that embedding it gives you a more powerful API. And of course all operations are defined with performance in mind. prepend is given to you since it's cheap, but if you want postpend you have to implement it yourself (it's a one liner, but clearly more expensive to the reader).

Little decisions add up to make the language feel great to use and genuinely impressive for learning new things.

[1] https://ziglang.org/documentation/master/std/#std.SinglyLink...

Consider the following Zig:

    // Vectors have a compile-time known length and base type.
    const a = @Vector(4, i32){ 1, 2, 3, 4 };
    const b = @Vector(4, i32){ 5, 6, 7, 8 };

    // Math operations take place element-wise.
    const c = a + b;

This compiles to this x86-64 code:

    vmovdqa xmm0, xmmword ptr [rip + .LCPI5_0]
    vmovdqa xmmword ptr [rbp - 48], xmm0
    vmovdqa xmm0, xmmword ptr [rip + .LCPI5_1]
    vmovdqa xmmword ptr [rbp - 32], xmm0
    vmovdqa xmm0, xmmword ptr [rip + .LCPI5_2]
    vmovdqa xmmword ptr [rbp - 16], xmm0

C does not provide vector primitive to expose the vector primitives in modern machines. C compilers rely on analyzing loops to see when auto-vectorization is applicable. Auto-vectorization is a higher level of abstraction than directly exposing vector primitives.

Regarding the lack of a standard global allocator, and the lack of implicit buffering on standard io functions, these are simply features of the Zig standard library which are true of computers (computers do not have a standard global allocator nor do they implicitly buffer IO) but are not features of the C standard library, and therefore are not encouraged to use custom allocators or explicit buffering.

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.

If you want to learn the actual mind changing aspects of the BEAM, clearly learning the simpler, smaller language with a more direct route to the juice is the way to go. Hence Erlang, not Elixir.

Also, in practice I would argue that Erlang is better over a longer period of time, but that's a hard sell for most people because it's very hard to accept that newer (and more complex) isn't better.

As a general point I'd like to state that I don't think it really matters what "people" do when you're learning for yourself. In the grand scheme of things approximately no one uses the BEAM, but this doesn't mean that learning how to use it is somehow pointless.

> Rust at this point is 10 years old from stable

Rust is not stable even today! There is no spec, no alternative implementations, no test suite... "Stable" is what "current compiler compiles"! Existing code may stop compiling any day....

Maybe in 10 years it may become stable, like other "booring" languages (Golang and Java).

Rust stability is why Linus opposes its integration into kernel.

> and isn't suitable for any of the domains where Rust excels.

That's a pretty bold claim since Zig is specifically designed for systems programming, low level stuff, network services, databases (think Tigerbeetle). It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs.

Higher up

> Rust is the small, beautiful language hiding inside of Modern C++

Cyclone for one, which AT&T created exactly to replace C.

Borrow checking is basically synonym for affine type system.

I wasn’t clear then. I would rather have N language features of increasing complexity/UX issues for dealing with increasingly complex situations rather than one mechanism to rule them all that can fail to instantiate in all cases (of whatever complexity). That’s the tradeoff that I want.

Why? Because that leads to better ergonomics for me, in my experience. When library authors can polish the interface with the least powerful mechanism with the best guarantees, I can use it, misuse it, and get decent error messages.

What I want out of partial evaluation is just the boring 90’s technology of generalized “constant folding”.[1] I in principle don’t care if it is used to implement other things... as long as I don’t have surprising instantiation problems when using library code that perhaps the library author did not anticipate.

[1]: And Rust’s “const” approach is probably too limited at this stage. For my tastes. But the fallout of generalizing is not my problem so who am I to judge.

> Okay, and I don't want any problem of any kind in my language, but unfortunately, there are tradeoffs in programming language design.

I see.

> So in practice, you either have one feature that can fail to compile in the client, or you can have the functionality split among multiple features, resulting in a more complicated language,

In my experience Rust being complicated is more of a problem for rustc contributors than it is for me.

> and still have some of those features exhibit the same problem.

Which you only use when you need them.

(I of course indirectly use macros since the standard library is full of them. At least those are nice enough to use. But I might have gotten some weird expansions before, though?)

That will have to do until there comes along a language where you can write anything interesting as library code and still expose a nice to use interface.

But the concern in this thread wasn't that people consider Zig or Rust good, so don't try to frame it this way, because it is dishonest.

Original quote:

> [Learning Zig] is about fundamentally changing how you think about software.

This is not the same. Something like it could be said about Lisps, Forth, Prolog, Smalltalk or APL, even Brainfuck, not Rust or Zig. No, thinking about object lifetimes or allocators is not "fundamental change" in how to think about the software. It is bread and butter of thinking about software.

> I bet you were one of the people who dismissed the iPhone as "just apple fanbois" back in the day

Wrong. I still dismiss people praising Apple, swallowing some bullshit about "vision" etc. as fanboys.