zig

Interesting, I hadn’t run across that but that’s probably just my problem domain. I did find this bug that looks like it was resolved a year ago https://github.com/ziglang/zig/issues/24184 and I have also read they are doing some other work on floating point that will hopefully address other cross-platform inconsistencies.

this! - the reason Zig defaults to one semantic analysis thread is due to current (to be improved) limitations; some ideas for Zig also will require one compilation unit - the restricted function pointers proposal being a good example: https://github.com/ziglang/zig/issues/23367 The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right

Zig doesn't currently have async/await in the sense that this post is about (i.e., async/await based on stackless coroutines). It previously had this, but it was removed last year (https://ziglang.org/download/0.15.1/release-notes.html#async...). The 0.16 release earlier this year introduced a much-heralded userland API (https://ziglang.org/documentation/master/std/#std.Io) that can be used to implement various asynchrony and concurrency patterns, including green threads, but it can't do stackless coroutines because support for those has to be baked into the compiler. There is currently an open proposal to bring back stackless coroutines without dedicated syntax (instead offering low-level bring-your-own-buffer APIs for interacting with suspended coroutines), which could be combined with the aforementioned userland API to produce somethin

> a plan to transition to it for C compilation That's not planned AFAIK (see https://github.com/ziglang/zig/issues/16269). `translate-c` is really only intended for header translation, not C source code. See https://github.com/ziglang/zig/issues/20875 for the (not fully fleshed out yet) plans around C compilation.

Zig does offer some amount of temporal memory safety. Link: https://zig.guide/standard-library/allocators/ Text: > The Zig standard library also has a general-purpose debug allocator. This is a safe allocator that can prevent double-free, use-after-free and can detect leaks. For more detail, see: https://github.com/ziglang/zig/issues/3180#issuecomment-5284...

> WASM-as-IR .. (Is that a thing?) Yes, actually I've heard of some projects compiling a language to Wasm, then using wasm2c to translate to C. https://github.com/WebAssembly/wabt/blob/main/wasm2c/README.... The Zig project does something similar for their bootstrapping process with a custom wasm2c implementation with just the features they need. https://github.com/ziglang/zig/blob/master/stage1/wasm2c.c I get the feeling this is an underappreciated technique with more potential.

no, but the documentation for packed structs gives the list of allowed field types. it's also not documented that packed union fields must be valid packed struct fields but people may be able to assume that edit: also, this is a relevant issue: https://github.com/ziglang/zig/issues/12547

I understand the reaction, but I don't agree. I suggest reading the associated proposal[0] along with the devlog, and having a real think about what's going on here. I'm responding to you saying that you "don't understand" the approach: reasonable, and resembles my initial reaction. I was inclined to agree with you, but what decided it for me is that Zig has another mechanism for "reinterpret bytes". It's exposed on the stdlib as std.mem.asBytes, but this is literally a wrapper for the following: @ptrCast(@alignCast(ptr)); So nothing is lost here: if you need, for whatever reason (and those do exist), to get a raw array of underlying bytes, you absolutely may. Std.mem also has bytesToValue(T, bytes) T, which makes a copy. All the ingredients are there, and this family of mem functions are thin wrappers over builtins, which boil d

I'm not familiar with D, but Zig and Rust are well-known for continuously evolving. Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329 And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc. (To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.)

Read through the stuff yourself if you don't believe me: https://github.com/ziglang/zig/issues?q=is%3Aissue%20label%3...

Doubt it: https://github.com/ziglang/zig/pull/24536

The truth can not simply be blanked out. Others can not be responsible for refusal to read, research, or any denial of reality. [1] Zig on GitHub has 3,042 open issues (as of this post) Link: https://github.com/ziglang/zig/issues [2] Tracking of Zig's strange star history Link: https://ossinsight.io/analyze/ziglang/zig#overview Note: historical changes in stars given to Zig, per month and year, have been recorded [3] Vlang has (for years) been ranked as a near or top 10 GitHub repo based on stars Link: https://ossinsight.io/collections/programming-language/trend... Note: vlang's quick rise and continual popularity is widely known for creating jealousy and resentment among its rivals [4] Zen C's star history compared to C3 Link: https://ossinsight.io/compare/c3lang/c3c/zenc-lang/zenc#over... Note: Zen C's quick rise in stars and emerging p

To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added): "To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability." The current interim plan (which I think

Way more suspicious star count looks to be from Zig[1]. That's based on their weird GitHub repo history[2]. In fact the initial negative campaigns initiated by the creators of Zig and Odin against V (and then turned on other languages like C3[4] and Zen C[5]), appeared to have been based on jealousy over supporter donations and GitHub stars. Zig, has among the weirdest GitHub star history of any language repo seen. Stalled or lower GitHub popularity, then sudden explosion in stars after the release of numerous AI ebooks on Amazon (mid to late 2024). The release of the mostly AI ebooks, were very oddly close together, as if by contract or bounty. Just a strange timeline. Even when Zig moved to Codeberg and their GitHub repo was "frozen", was getting hundreds of stars per month (despite over 3,000 open issues) for a long time, which made no