audunw

For posterity here are some comments I’m curious if will be deleted

1.

Id like a clarification on how this is safer than Rust?

(Seems reasonable enough)

2. meme image with the words “bait” and “retarded” - should be deleted

3.

Funny how memory safety suddenly became a priority right after Bun moved to Rust. That feels like a pretty big departure from Zig's original philosophy.

Someone's still pretty butthurt about Jared and the Bun team.

Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT

I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig)

And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted.

Serious comments seem to be kept, even when they’re sceptical.

I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much.

I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?

“I'm tired to see zig head people trying to diss Rust whenever they can.”

I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing

I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software

I think the point here is to include C library dependencies. Which GC languages in general consider outside the scope of its memory safety.

“Here is the catch: that single integer is wearing three hats at once.”

How many times did that point have to be reiterated in unnecessary AI style?

Was the article AI generated. I hope so, if not it really shows how bad AI has degraded our ability to write. Could you at least have read over and cleaned up the prose a bit? That whole section could have been written in straight forward human language, and it would be shorter, clearer and less infuriating to read.

Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.

I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)

Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.

I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.

That’s totally reasonable. But while each minor version has breaking change, a minor version release itself is generally fairly stable and useable. There are solid production software which is already using Zig, like TigerBeetle and Ghostty/libghostty.

I am waiting for (near) 1.0 myself before doing anything major with it. But that’s mainly because I want at least the async IO stuff to be settled for my use cases.

Did you read the article at all?

Zig itself is an incredibly fast compiler. And the language and standard library is designed to support writing that compilers. And yeah, that’s all about algorithm and data structures. A large part of why struct-of-arrays is easy to do in Zig is because Andrew wanted it for making the compiler fast. The article also points out that it’s reusing code from the Zig compiler source as well.

Roc may not be super fast now, but that doesn’t mean they haven’t seen ahead and set themselves up for success.

Yeah, I agree there is value in self-hosting as you say. Zig itself is an example of that. But zig is a systems language. If Roc isn’t aiming for that nice it might not be the best choice for writing a compiler in. As an example in the other extreme end of language flavours: Python is still mainly CPython and efforts to make a python interpreter in some variant of python hasn’t been particularly successful.

The tests and the numbers are interesting. The LLM writing style? Insufferable.

It really wouldn’t have taken much effort to cut out the worst of the AI fluff, and maybe add some human touches

The results improving the end user experience didn’t have much to do with the rewrite. Improvements in binary size and speed could be had with similar efforts on the Zig codebase. They spent extra effort to get those metrics to look good to sell the rewrite.

The memory safety aspects could be discussed. Arguably they could have had equally good memory safety by employing AI, tests and fuzzing (the Zig integrated fuzzer that the Zig team suggested they use, not just the high level fuzzing they were doing)

For this kind of project I do think using Rust is a good idea. At the very least because a project like Bun probably can benefit from a more mature language.

But I also think Andrew’s perspective of this process has been essential to understand what happened here, and though he could have been nicer with his word selection in a couple of places (he doesn’t have the clout of Linus Torvalds to get away with it), what he wrote absolutely needed to be said. I find it annoying that people dismiss it as personal attacks. If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks. It’s essential context for understanding what happened.

How can it linger in a higher orbit. Maybe some of the debris gets a kick which increases its velocity, but you need two velocity boosts to circularise the orbit, no? So I figure at worst you get an elliptical orbit which will still decay

I have the exact opposite impression. From everything else I’ve seen around Andrew and the Zig Foundation he is extremely professional and skilled with managing community. In fact I’d say the community and management of the project is Zigs biggest strength.

This blog post only reinforces this opinion. It is clear that the Zig developers has had huge issues with his relationship with Bun for a long time, and it seems from both Jarred and Andrew’s post that Andrew really put all those issues aside, in spite of his strong personal opinions, to maintain a professional and productive relationship as long as possible.

It’s only now that the relationship is broken (on Buns initiative) that he has taken the opportunity to vent a bit. And I’m really glad he did.

It’s similar to Linus. Sometimes Linus goes too far in his comments. But getting an occasional insight into people’s personal opinion is good, as long as it’s not at the cost of breaking a professional relationship.

I didn’t read the beginner energy comment as faux positive at all. In fact Andrew has commented about his own beginner energy just recently and shared some embarrassing forum post he made as a teenager.

Stinky manager.. I could see, but even if his wording was more polite he’d still be criticised just as much, people would just say the personal criticism is “thinly veiled”.

We could argue a lot about how he should have worded himself, but in the end he wanted to (and had all right) to talk about how Jarreds coding and management style affected their professional relationship. According to commenters here on hacker news it seems like he simply is not allowed to talk about that. Even if he goes as far as possible in making it explicit that it’s not personal.

You didn't see K&R publish "so-and-so writes bad C", or Stroustrup decrying the Boost maintainers as hacks.

The world is completely different now. The VC fuelled culture was not as intense and LLMs certainly didn’t exist at all. Andrew calls out these factors explicitly.

He can't have both "It's their fault because their code was slop" and "it's not my business".

Huh? But it was his business when they had a relationship. Seems he was trying his best to work with them while they were getting funding and Bun was interested in them. That’s the nice thing to do no? Even if you don’t like the partner.

Imagine if the Zig foundation broke the relationship from their side, that would have been much worse.

I don’t think Andrew was trying to say it wasn’t his business in that way. But in the end he couldn’t control what Bun did or didn’t do, and now it’s not his business in any way.

How often do stuff fall of the rails, and how common is derailment? In case of derailment you’ve got much bigger problems than some broken solar panels.

It’s not easy though. When we started with html we assumed images could only have one source. It was obvious that cardinality was 1. Later we realised we could have multiple versions of the same image. With audio tags that was resolved.

I’ve come to realise that it’s almost always a mistake to assume a cardinality of 1, unless it’s something that is defined to be artificially unique like the id attribute.

I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.

Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.

I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.

The most interesting killer application for Zig is perhaps Ghostty and its library libghostty, which will probably be fairly easy to integrate with C apps since Zig is close enough to C.

There’s also Tigerbeetle, but unlike libghostty its use of Zig doesn’t have much chance of being viral.

I think libraries that can be used by many other languages is Zigs chance to wide adoption. And this ties nicely with Zigs fantastic build system, which may become increasingly popular for C based projects, especially where cross compilation is important.

I assume the compiler(s) do not run in WASM. Just the build script. The build script just orchestrates the compilers. So you can run any compiler that the build script is given access to, so compiling C/C++ or potentially any other language shouldn’t be an issue.

In theory, you could run the whole compiler (including C) in WASM as well but I don’t think that’s the goal? You kinda need to trust the compiler itself.

I truly don’t understand what value a JIT would provide here. Especially in Zigs case. The language allows for full pre-compilation and the compiler is so blazingly fast it’ll finish compiling faster than the startup time of some interpreted languages. So what would adding an interpreter/JIT achieve? Absolutely nothing.

Seems to me the idea of using a JIT here is just because it’s fashionable, not because it solves a real problem.

PUFA vs saturated fats come with a lot of caveats. It's generally good advice to avoid saturated fats, but there are only certain conditions in which saturated fats are unhealthy and we don't fully understand those conditions yet. Saturated fats from dairy is even more complicated. It's may not be as bad as other saturated fats.

Recently there are very good studies tracking heart disease progression with extreme accuracy and it is very clear that you can eat high amount of saturated fat for a very long time with zero CVD progression. The mechanism depends on other factors.

Still, personally I think it's good advice to reduce saturated fat until we understand these mechanisms better. Eventually though, I suspect we will find other interventions that eliminate the CVD impacts of saturated fats.

I gotta imagine that margarine with EVO is a clear winner, EVO has several great benefits. Not saying processed seed oils are bad.. I'm not in that camp. Evidence for that idea seems very flimsy.

I really think the best way to describe it is an attempt to replace C.

Go is only like C in that it's simple. But it's clearly not a direct C replacement. It's not a great language for writing an OS or embedded code.

Rust may replace C in many contexts, but Rust is much more like C++. It adds a lot of complexity to the language and the compiler. I think it does it in a much better way than C++ so I think it is more likely to replace C in certain contexts where C++ did not replace C.

But Zig really is a much more direct replacement for C. It's aiming at the same niche, but in a different way. And considering how much C still dominates systems programming, it should be pretty clear that if Zig succeeds in become a good replacement, the answer to your question is: you'd reach for it whenever you'd have reached for C before.

The only question at this time is if Rust will eat so much into that niche that what's left for Zig becomes too small. Though it could go the other way. Zig is simpler and easier, and you can iterate really quickly with it. There's even incremental compilation now. I suspect tests with debug allocators, the integrated fuzzing, static analysis and LLM assisted reviews, can make Zig just as safe as Rust in practice, with far less complexity. So maybe Zig will eat into Rusts niche (whenever Zig is mature, right now it's going the other way as seen with Bun)

The scale of Apple is such that I suspect they also set prices based on what would lead to shortages. If they had significantly lower prices, to avoid annoying customers by not having things in stock, they’d basically have to fund the construction of new factories. They do do that kind of stuff, but it’s not trivial.

I’ve followed Zig fairly closely and this is the first I’ve heard of Andrew pushing “social issues”. I don’t believe for a second that it’s a factor at all.

I may be damaged from working on IC hardware design and various weird architectures, but I truly can’t comprehend why you’d think this doesn’t make sense.

Yeah, if your architecture doesn’t support 24-bit int it maps to 32-bits. But it also declares that the numbers you’re storing should never be larger than 2^24. It’s about type safety, and also run time checks in safe mode I believe. Bitcasting three bytes to a 24-bit type makes just as much sanse as casting 4 bytes to 32-bit. Theres zero reasons to introduce arbitrary artificial constraints on what you can do based on details of (most of) the underlying architectures, which doesn’t even matter for the operation you’re performing.

Maybe those complaints are for datacenters using gas turbines for power. I think some of the recent ones (xAIs?) was built without sufficient power from the grid.

I only started watching it after I got spoiled, and didn’t mind it. Before I knew about the premise I thought the show looked boring. Didn’t pick it up based on the excerpt on Netflix.

The show doesn’t really rely on not knowing the twist. And even saying there’s a spoiler for season 1 will probably clue most people onto what the twist is anyway

Heating is one of the easiest to pair with intermittent power. Heat storage “batteries” can store energy for a very long time. Stockholm recently converted an old cave used to store oil, which now stores heat for a district heating network

There is definitely an economic changeover point, I’m sure I read they will use conventional drilling down to a certain depth, before switching to MMW

I doubt argon is the purge gas.

Shutting down nuclear power plants prematurely was very foolish (looking at you Germany). But other than that, it’s true.

When you boil the issue down to the fundamental facts, our challenge is simply: add as much power production as fast as possible. We have no other hope to tackle the issue but to optimise for this. Nuclear is a dangerous distraction. Solar+wind is now growing faster than nuclear ever did at its peak and they’re showing no signs of slowing down. It’s the only way to get more power fast enough.

We are building power for a future where we cut all CO2 emissions. Not just those from electricity. Our second biggest priority (well third after EVs, but I’m not too worried about EVs right now, it’s a self sustaining transition) is to bring down the capital costs of hydrogen plants. That’s the key to bringing down CO2 emissions in several sectors of industry. This pairs perfectly with variable power. We’ve already seen green ammonia fertiliser plants paired with renewables and now with the Iran crisis there will be higher pressure to build more of them to be self sustained. This way also lets us distribute production which is nice to be less vulnerable in case of war.

Once green hydrogen production has reached critical mass, and growth of renewables have pushed gas power plants into more of a backup role, with low fuel consumption, they will naturally switch to hydrogen. Many of the newer ones are already ready for hydrogen and others have an upgrade path. Perhaps hydrogen consuming industry will co-locate with gas power plants to share production/storage infrastructure. This path has very low capital costs besides the ones we anyway need to make the hydrogen necessary to decarbonise industry. The gas power plants are already built in most countries that will need them.