Nice write up ! I think it would be nice for Zig to try to catch some of those errors like return of stack pointers, Cause it's painful for beginners

If you think this paper is pro-C++, read it again:

> many languages like C++ or Java are now old enough that if they would have > offered significant advantage over C, they should have supplanted C by now, > this clearly hasn’t happened.

I don't agree with all the points though and the rhetoric is pretty weak IMO, like the point about cars being safe for pedestrians.

But I agree with the points about C being simple and having great tooling (thanks to being simple).

ZML the zig library is mostly a wrapper of StableHLO/pjrt. But it's a high quality wrapper, and the tagged tensor syntax is really helpful to write complex ops like dot, or gather.

And ZML the framework also resolve issues with the complex dependency graph of stablehlo/pjrt.

Zig has been relatively stable for the past few years for the main Zig code. What has changed the most is the `build.zig` build system (which we aren't using).

We are also looking ahead at Zig roadmap, and trying to anticipate upcoming breaking changes, and isolate our users from that.

It' s a bit early to compare directly to TensorRT because we don't have a full-blown equivalent.

Note that our focus is being platform agnostic, easy to deploy/integrate, good performance all-around, and ease of tweaking. We are using the same compiler than Jax, so our performances are on par. But generally we believe we can gain on overall "tok/s/$" by having shorter startup time, choosing the most efficient hardware available, and easily implementing new tricks like multi-token prediction.

Hi co-author here. Zig is way simpler than C++. Simple like in an afternoon I was able to onboard in the language and rewrote the core meat of a C++ algorithm and see speed gains (fastBPE for reference).

Coming from Python, the hardest part is learning memory management. What helps with ZML is that the model code is mostly meta programming, so we can be a bit flexible there.

We have a high level API, that should feel familiar to Pytorch user (as myself), but improves in a few ways

Very nice read.

I agree with the author that Zig should improve a bit the readability of integer and vector arithmetics.

Small tips is to use more lines.

  fn addOffset(base: u16, off: u8) u16 {
    const ibase: i16 = @bitcast(base);
    const ioff: i8 = @bitcast(off);
    return @bitCast(ibase +% ioff);
}

Why do we tax income though? Especially for billionaire in a globalized world, it's easy to hide incomes. Wealth is harder to hide.

I am not arguing that taxing income or wealth is right or wrong. Only that given how current taxes CURRENTLY work, TFA's controlled outrage is idiotic.

Graphic 5.2 in http://piketty.pse.ens.fr/files/Piketty2019GraphiquesTableau...

In France it was down to less than 1% at the time of Revolution, but some countries like Spain that had centuries long wars, was closer to 6-8% range.

I wrote a similar article but focused on how Zig design enable better optimizations than C. https://zig.news/gwenzek/zig-great-design-for-great-optimiza...

Meh. In your article, you could always mark the function f() as pure or const and get the hoist