I think that post highlights a difference in philosophical approach to software development. Bun is focused on moving fast and will deal with the consequences as they come. Zig takes a more planful approach.
I've experienced both in my career and I fall solidly on the planful side. It's why stopped using homebrew and I've avoided huggingface packages as much as possible.
Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.
> Two, I actually don't have any personal criticisms of Jarred
The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.
> Jarred was already writing slop well before he had access to LLMs
> The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience
Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.
All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.
I don't think it was written by AI but rather edited with help of AI.
There are just a few obvious AI lines in the text.
Not great, not terrible but it immediately caught my eye.
yeah it turns out that complex code, when its properly encapsulated and implemented in a bug-free manner, is not such a cost after all.
A correct skiplist is easier to NIH than a correct red-black tree (which for me was the final boss of the DS class in college), but has performance edge cases a red-black tree doesnt, if you treat it like a search tree.
I think it was more about binary size. There are a few sentences in the Qt containers documentation about them being "optimized to minimize code expansion".
I mean that could mean a lot of things. By default, in C++, an std::vector<float> and std::vector<int> are two entirey separate classes with distinct methods getting compiled, even though in this particular the methods would be identical. Moreover, since templates are in headers, every object file gets their own compiled copy.
I'm sure there's some cleverness in there to mitigate the problem somewhat, but the problem still fundamentally exists
You can mitigate this manually to some degree, by making the generic classes call out to non-generic functions, of which there's guaranteed to be just 1 copy. I'm guessing that's what Qt does (among other things) when mentioning this
Sorry if this is a dumb question but wouldn't vector<float> and vector<int> generate different code on get/set? Since floats go in different registers/need different instructions to load/store them to memory? Or is it something like, actually all of the std::vector functions technically operate on T&, and manipulating the pointers can use the same code, and really it's the optimizer that has to think about float vs int registers or something
