Glad to see "Together we serve the users" come back. I miss the old Zig readme that said Zig comes with an MIT license and a humble request to build software that serves the users.
My question was genuine: what makes the Zig devs apart from the others, according to the question op?
Arguably, there are important things that Zig devs are doing which are not "Zig dev made" (hence the "giants" I mentioned). NASA 10 rules are now rebranded as "tiger style" and marketed along Zig; Data Oriented Design existed before Zig; LLVM existed before Zig; the authors of gpui, the library that seems to have inspired gooey, apparently did a pretty great job (please correct me if I'm wrong, I don't do graphics, don't use gpui, this is what I understood when gpui came out).
I'm sure Zig devs made pretty great things, too! Does Zig make them apart? Do Zig attracts more capable devs than other languages, maybe? Genuine question!
I take issue with the statement that "tiger style" is marketed along with Zig. Tiger Style is neither convention nor standard, it's not on ziglang.org, it's not referenced by the Zig Core Team as the end all be all. At present I don't recall them ever referencing it, but I'm sure they have talked about it somewhere.
On the subject of Data-oriented design, it's mostly just the default way of thinking about software in most contexts. The DoD movement is not so much building on predecessors as it is ignoring predecessors who tell us to use OOP and "clean code" for everything.
LLVM is the part of Zig that breaks the most, it's the slowest part of the compiler by leaps and bounds, and takes the most time of the core team to fix the constant breakages it introduces. I'm glad it exists obviously, to some extent, but I wouldn't praise it for much more than its widespread appeal and ease of "adding another pass" compared to GCC and having more of a company-friendly license. It could have been designed a lot better and could be managed very differently and we'd see better results.
GPUI - I bet it's great. I guess I just tend to dislike phrasing like "stand on the shoulders of giants" because I tend to think the best thing hasn't been built yet. "Real engineering has never been tried!" I agree though that an AI port of a Rust library to Zig is probably not what any of us consider the holy grail of engineering.
In short, I think Zig and TigerBeetle and the Handmade Ethos exist not primarily because others paved the way, but because others went astray. Andrew Kelley used to argue with people online about how cross-compilation should be easy for systems languages and got hit by the excuse parade every time. Eventually he decided to quit his day job and solve it himself. Is that standing on the shoulders of giants? I don't think so. Yes, he has technically picked up where others left off, but he's picking up on abject failures and fixing them.
Now there is good engineering within LLVM and Clang, and good developers have done good work on it. I'm not saying everyone who worked on it is stupid or did bad work. However, there are glaring issues at a macro level and organizational level that individual contributors can't fix.
Justine, first I'll say I love APE and redbean and your articles on the code trickery you get up to. Of course, I hope you keep creating amazing software for us all to enjoy.
I want to zoom in on this:
"I am the intersection of so many unliked groups whose minds I've come to understand. If you were to use bayesian inference to compute the probability that I'm a good person, it would underflow a double. In practice, this just means I'm a curious person who hasn't had much to fear, since I've never had much to lose. If the day should ever come when society chooses to accept me, then the negative attention I've received will be viewed for what it really was, and then people will be able to safely examine my lifelong track record of kindness and conspicuous public service. All of the people I've talked to in my life will be influenced by my example and then stand a better chance of flourishing thanks to an increased interest in understanding."
I don't know your life, but I think it's more than possible that it's not merely a coincidence that you're at the intersection of so many unliked groups.
My brother once sent me a picture of a furry wearing a swastika armband asking if it's a real thing. My first reaction was a giant "WTF?!". My second thought was, you know, on some level, I gotta respect the hustle.
Someone really thought, "How can I be as revolting as possible to everyone? I can't LARP as a nazi, because then nazis would like me. Becoming a furry isn't enough either, because then furries would like me. But if I can stand at the intersection of all causes of disgust aimed at our fellow beings, then I will have proved my case."
I think the point of this line of thinking is different for different people, but the motivation could be a) because you want the world to hate you as you hate yourself b) you want to embody the negative underbelly of humanity to be a mirror so society or individuals within it can see their true nature. You want to have stones casted at you to prove that the rest of us are, in fact, the type of people who cast stones. Or c) it's just funny in some depraved way, "for the lulz" as they say. But, I assume you're already way past the point of laughing at the ridiculousness of this tired dance. You're a middle-aged adult who is struggling.
Well I, for one, won't cast a stone your way. I genuinely don't hate you at all. I admire your boldness and tenacity. "Donate so I can buy a private jet" is gold. I didn't really appreciate the mania or hyper-fixation roller coaster the article took me on, but I just found it unfortunate because I don't think this is the best way of thinking you could employ.
If at all possible, I think you should just try to be a "normal person" and think that that's an okay thing to be. By "normal", I mean not putting yourself in the crossfire. I still think you can and always will be technically extraordinary, and I don't think that's contradictory. You merely stop seeking rejection.
It seems to me, even as divisive as you may be, there have been many earnest attempts to integrate you into regular society, give you a super high paying job, and bring you into a context where you can innovate and push humanity forward. Why not just let that happen? Why not de-politicize just a little bit?
People will hate me for saying this or think I've licked too many frogs (I've never not been sober btw), but I have come to see a lot of political posturing as more arbitrary than not. I still know people have different visions for the world, and ideological differences that matter at a macro level, but to me, what really matters in life is looking other human beings in the eyes and having a connection to them. Sitting inside, alone, typing on a keyboard or phone, is anti-social, and it is against the nature of a human being.
I'm not telling you to give all of it up. But hopefully I've evoked at least one thought that encourages you to walk a path with a better outcome. You don't deserve to suffer your whole life, waiting for the world to accept you. I am sorry to hear about the tax situation and people who really have targeted you. I genuinely care and hope you find peace and healing on the inside. And stop reading internet comments.
The root cause problem seems to be that people who are highly intolerant to others' views and perspectives that they happen to disagree with have become an outsized voice in tech circles. Shunning, blacklisting and publicly denouncing has become a toxic norm.
Justine has expressed unorthodox views in the past but that's no reason to punish him forever, or indeed at all. To be as inclusive and tolerant as possible - towards an end goal of maximizing participation and enabling outstanding technical work to flourish - it is better to simply agree to disagree.
If we want to improve cross-platform SIMD, in my opinion we should start by supporting more operations in LLVM IR. Like vector expansion (currently we only have expandload), runtime-known shuffle vectors, pdep/pext operations.
Also, let's stop with the "vector length agnostic" types being the sole option for SVE extensions. I'd rather write an optimized routine for a 16-byte machine I'm targeting and be able to upgrade it in 5 years than have "agnostic" code that wants to pretend like it would work amazingly on all platforms, but the machine I optimized it for is theoretical. I'm fine with recompiling my code, I do it every day. If I have an algorithm that's truly vector length agnostic, I can make the vector length a constant in my code that can change based on the compile target.
> Also, let's stop with the "vector length agnostic" types being the sole option for SVE extensions
They aren't, see the `arm_sve_vector_bits` attribute.
> I'm fine with recompiling my code, I do it every day
Then you can do that.
> If I have an algorithm that's truly vector length agnostic, I can make the vector length a constant in my code that can change based on the compile target.
You can do that, but why not simply write it in a vector-length-agnostic way?
IMO the better approach is to start thinking about SIMD optimizations in a VLA way, and specialize on the vector length, when that becomes advantageous.
Doing it this way is better even if you end up not writing VLA code, because you though about the scalability problem.
Many libraries currently don't scale beyond 128-bit, not because they couldn't make efficient use of >128-bit, but because the library was architect around 128-bit and changing that amounts to almost a full rewrite. So now you are stuck wasting 3/4th of your ALUs running 128-bit SSE on Zen5.
I'm team Zig in most cases but I genuinely think they are better off with Rust. They have had a lot of buffer overruns and segfaults as a result of undisciplined Zig code. I think Rust actually is a better technical choice for them.
I don't think that's going to save them. There are big problems and little problems. RAII+ownership/borrowing solves some memory and file handle issues. But the big problem and this happened before the rewrite, is that they have ceded the system level. Which locks the project into a local minima.
It's not a "your holding it wrong" problem it's a you fundamentally have no idea how your own program works past 1 or 2 level of indentation in most places. If the LLM says that something isn't possible you just have to take it at it's word.
I'm a full time Zig developer, and I see this as an absolute win. I know Jarred has said in the past he feels Zig makes him more productive, but I also think it's fair to say Bun was programmed in a way that's quite cavalier towards buffer overruns. I think Jarred and the Oven team will have significantly better luck with Rust.
Some commenters have remarked they only heard of Zig because of Bun, therefore this is bad for Zig. Not so. In my opinion, there has always been a mismatch. I say with no ill will that a divorce is likely better for both parties. I genuinely believe Bun will be better software once fully converted to Rust.
I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none.
Even now:
bun (zig) [1] 119 open / 885 closed
deno (rust) [2] 0 open / 1 closed
I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job.
Not sure why you're getting downvoted; I think you're close to right. They were successful with one technology and had a great exit. They may also be successful with another technology post-acquisition.
I am personally moving in the opposite direction. I haven't meaningfully used a signed integer in years, and I see signed integers as being for more niche use-cases. I mainly only use a signed types when I want to do a "signed shift right". If there was a >>> operator in Zig I wouldn't even think of signed integers.
Given your examples, I think you'd have fewer issues if you were working with unsigned integers exclusively. Although I'm curious about what other code you were referencing with this:
"But seeing how each change both made the code easier to reason about and more correct, I couldn’t deny the evidence."
With regards to modulo, in Zig if you try to use it with a signed integer it will tell you to specify whether you want `@mod` or `@rem` semantics. In my case, I'd almost never write `x % 2`, I'd write `x & 1`. I do use unsigned division but I'd pretty much never write code that would emit the `div` instruction.
I'm not saying you're wrong though! Everyone has a different mind. If you attain higher correctness and understandability through using signed integers, that's great. I'm just saying I'm in the opposite camp.
Zig also differentiates between the wrapping and non-wrapping operators. The for loop example would toss a runtime error when the index underflowed in most compiler modes.
The if statement won't work since Zig would force a cast.
The tricky wrap sucks unless you use a power of 2. Then the Zig type can match (u4, u5, u7, etc.) and you would use wrapping arithmetic operators. And on smaller CPUs you NEED to use a power of 2 because division and mod are expensive.
I like to read assembly a lot, and I don't really see the point in WASM trying to be a stack machine. None of our computers are stack machines.
Not to mention that compiler backends are missing tons of optimizations even on mainstream targets on real hardware, I just don't think WASM makes sense economically. They should have just picked RISC-V and called it a day.
Can we call it a D2? I'd call it a non-monetary-gaming-fair-coin, but it's hard to reduce it to a 4 letter word like "coin" or "dice" that most people would understand.
Yes, but I'd prefer some more specificity to the shape. D2 can be coin shaped, but don't have to be. There are some diverse shapes in the image of the article.
IIUC "chip" is just a token that represent money, they are not necessary "fair", they are not good to be tossed.
I imagine a parallel world where chips are shaped like empty cones, so they can pilled but they are very bad as a D2. (Perhaps a world where chips are shaped like cubes is more realistic, also bad as D2.)
reply