gwenzek

That's not what the article says though. The size reduction was from extra linker flag for deduping code, and the speed gains from LTO.

They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.

I really don't like this move. I always rooted for Android because of its openness. It was also a reason why I was proud to work at Google.

The PlayStore is full of crapware, and I'm using a lot of apps from Fdroid, including basics like keyboard and text.

If you're at Google try to push back on this please.

Interesting to see the new C++ at work. But also I'm sure it's easier to learn Zig full language that just the new C++ metaprogramming

Really liking the promotion of "Unmanaged" containers. It's the ones I'm using everywhere already

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.