zig VS llvm-project

Actually, nobody.

Here is the commit where Reader/Writer was introduced: https://github.com/ziglang/zig/commit/5e212db29cf9e2c06aba36...

This is a few months after `git init`. You can see I was really just working on the parser, with a toy example to get things started.

Over time, I merged contributions that made minor changes and shuffled things around, and these APIs evolved to kind of work okay. But nobody really considered "the Zig IO stack" as a whole and put in design effort. That is happening for the first time right now.

This list's Zig as an entry, despite the Zig project having very clear plans[0] for a 1.0 release. That's not 0ver, it's just the beta stage of semver.

[0] https://github.com/ziglang/zig/milestone/2

I usually structure teaching the same way done in https://www.writethedocs.org/videos/eu/2017/the-four-kinds-o.... So "the Quick Walkthrough Guide will explain what dk scripts are and give you small examples to run" is simply a learning-oriented tutorial which is mostly about giving students confidence and visual feedback. And simultaneously it an explanation of nothing (the video has a great explanation for why to do that). So, I agree that an explanation of threads + Internet + cross-compilation would quite nuts, but for an experienced developer I'd expect to see a meaty example (take a look at https://ziglang.org/ for comparison).

One concrete action may be to make two distinct Quick Start guides ... one for the experienced and one for the inexperienced students though. Is that your thinking?

> I feel like I can write powerful code in any language, but the goal is to write code for a framework that is most future proof, so that you can maintain modular stuff for decades.

I like Zig a lot, but long-term maintainability and modularity is one of its weakest points IMHO.

Zig is hostile to encapsulation. You cannot make struct members private: https://github.com/ziglang/zig/issues/9909#issuecomment-9426...

Key quote:

> The idea of private fields and getter/setter methods was popularized by Java, but it is an anti-pattern. Fields are there; they exist. They are the data that underpins any abstraction. My recommendation is to name fields carefully and leave them as part of the public API, carefully documenting what they do.

You cannot reasonably form API contracts (which are the foundation of software modularity) unless you can hide the internal representation. You need to be able to change the internal representation without breaking users. I hope Zig reverses this decision someday and supports private fields.

> Did Zig really do that?

https://github.com/ziglang/zig/issues/544#issuecomment-61807...

> In order to simplify everything, tabs are not allowed. Spaces are necessary; we can't ban spaces.

They seem to be open to the alternative but not to a solution that isn't forced on people:

> Maybe someday, we'll switch to tabs for indentation, spaces for alignment and make it a compile error if they are incorrectly mixed

Zig already has a builtin code formatter that automatically changes formatting to their preference, but that's not enough.

Zig solved this by not having a string type at all and not shipping full Unicode support in std: https://github.com/ziglang/zig/issues/234#issuecomment-27630....

Bun is written from scratch in Zig, a low-level language focused on performance and safety. Instead of using V8 (the engine behind Node and Deno), Bun runs on JavaScriptCore, the engine used in Safari. This choice helps it stay fast and efficient, both in terms of memory and startup time.

The most interesting part of this post is the bit about half way down, where Alex uses Claude to help identify a missing compiler optimization in LLVM... and then uses Claude Code to implement that optimization and gets a PR accepted to LLVM itself! https://github.com/llvm/llvm-project/pull/142869

it's mostly upstream now, no need to dig around in their repos

https://github.com/llvm/llvm-project/tree/main/clang/tools/c...

> Are you saying the model used to simulate many different cpu models is the same, which makes comparing CPUs harder? Or are you saying the model is not accurate?

Both, but mostly the former. You can view the scheduling models used for a given CPU here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ...

    * CortexA53Model used for: A34, A35, A320, a53, a65, a65ae

3. Clang-LLVM + Windows SDK + Cmake + jom (and Windows CRT from C3 install) => Works fine https://github.com/llvm/llvm-project/releases/download/llvmo...

(I use 3 for D too)

I would like to add toyour guide with OpenWatcom V2 (https://github.com/open-watcom/open-watcom-v2)

These files exist (https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ...) but it is very complicated because the processors themselves are very complicated.

I used Cline+Claude 3.7 Sonnet for the initial draft of this LLVM PR. There's a lot of handholding and the final version was much different than the original.

https://github.com/llvm/llvm-project/pull/130458

Right now I'm using Roo Code and Claude 4.0. Roo Code looks cooler and draws diagrams but I don't know if it's better.

https://news.ycombinator.com/item?id=43888005

> In a non-inlined, non-PGO scenario the compiler doesn't have enough information to tell whether the optimization is suitable.

I guess you're talking about stores and load across function boundaries?

Trivia: X86 LLVM creates a whole Pass just to prevent this partial-store-to-load issue on Intel CPUs: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ...

Do you like have any idea what you're talking about? Or are you just making it up for internet points? The target is part of the input.

Lemme ELI5

https://github.com/llvm/llvm-project/tree/main/llvm/test/Cod...

You see how this folder has folders for each target? Then within each target folder there are tests (thousands of tests)? Each of those tests is verified deterministically on each commit.