zig

Have you been following https://github.com/ziglang/zig/issues/16270 ?

Andrew’s point is that marking the memory as volatile should prevent this optimization. (i.e. the compiler isn’t allowed to split a 16-bit volatile write into two 8-but writes.) This is idiomatic because volatile is intended for MMIO. There’s a proposal for a way to disable LLVM generating builtin calls like memcpy. But I’d argue volatile would still be more appropriate in this case. https://github.com/ziglang/zig/issues/22110 Edit: this comment from later in the thread is also relevant: https://news.ycombinator.com/item?id=42556624

A few notes: 1) Lack of a garbage collector does not make your program faster, it makes the performance more easily predictable in terms of latency. It also makes it more friendly for memory bandwidth, CPU cache and to overall memory usage, which in turn results in better performance in real-case scenarios vs synthetic/toy benchmarks. This is particularly noticeable in constrained environments (like embedded systems). 2) Zig was never about memory safety, and it is not a memory-safe language. It might have better plumbing than C, it might add better way to implement and abstract concepts.. but so does C++, for instance. The more striking differences between C++ and Zig, IMHO, are syntax and the ability to use the same language instead of a separate one to do meta-programming (templates vs comptime). 3) Aliasing enforcement in Rust is ther

Rust's approach is more like a "keep off the grass sign" than a barbed wire fence. If Rust really wasn't meant to be used for these things, it wouldn't have the unsafe keyword at all. But instead of forbidding those things entirely, it just makes them uncomfortable. This nudges the programmer to question if they really need to be on the grass to accomplish their goal, and helps subconsciously steer them onto the safer path. This is the "strategic use of friction" described here, ironically enough, by the creator of Zig: https://github.com/ziglang/zig/issues/3320#issuecomment-8844...

It's an alternative to OOP. You can get there via a series of transformations: 1. Start with OOP (heap-allocated objects with shared base structs) 2. Transform to using tagged unions instead 3. Transform to the approach outlined in the OP (I call it the "encoding" approach in this talk: https://vimeo.com/649009599) It's handy because you get to use an index to refer to an object, and you get serialization benefits. The zig compiler uses this pattern in quite a few places: * https://github.com/ziglang/zig/blob/77c63ac36034db577a9287c5... * https://github.com/ziglang/zig/blob/77c63ac36034db577a9287c5... * https://github.com/ziglang/zig/blob/77c63ac36034db577a9287c5... * https://github.com/ziglang/zig/blob/77c63ac36034db577a9287c5...

IIRC there's `zig reduce` builtin in Zig :) https://github.com/ziglang/zig/blob/master/lib/compiler/redu...

Reminds me of a Zig proposal I saw recently to make the std.Thread.Pool API respect the Linux jobserver and macOS dispatcher automatically out of the box: https://github.com/ziglang/zig/issues/20274

There's an issue tracking that: https://github.com/ziglang/zig/issues/3806

I do not know Zig either; I had assumed that it has default parameters, but it seems that it does not[0]. So, yes, it makes sense now why it cannot be elided. They should add default parameters to avoid this sort of thing. Maybe they ought to consider named/labelled parameters, too, if they're so concerned about clarity. 0: https://github.com/ziglang/zig/issues/484

Welcome to 2016. https://github.com/ziglang/zig/blob/5f0bfcac24036e1fff0b2bed...

Can't wait for Zig team to adopt this over libc, citing concerns about "libc not existing on certain configurations"[1] [1] https://github.com/ziglang/zig/issues/1840

Indeed, Zig does this for instance (at least for x86_64 linux [0]) as a way to avoid having to link libc at all [0] https://github.com/ziglang/zig/blob/ee9f00d673f2bccddc2751c3...

> will that function also get to return a u8? No, the main function (the entry point of the entire program) is special cased. Have a look at the source code. There you can see it's calling the user defined main function and handling its return value / error. https://github.com/ziglang/zig/blob/2d888a8e639856e8cb6e4c6f... > Also, what happened to argv/argc? You can access argv with std.os.argv which is a slice of null terminated strings. It's better to go with std.process.argsAlloc though (requires an allocation but works on all supported platforms).

I'm a bit hesistant to mentally invest in Zig, given the maintainers choice to directly develop against a mostly undocumented NT-API instead of the Win32 API. [1]: https://github.com/ziglang/zig/issues/1840