kristoff_it
Joined 10 years ago
Karma
5,909
Submissions
702
Member since
Feb 19
Recent submissions
Comment · 3 days ago
We used to have a version of ArrayList that bundled an allocator in the stdlib, we removed it because our experience having written Zig code for a few years led us to reach for the allocator-less variant almost always.
One aspect your argument is missing is that if you are juggling many ArrayLists, having each bundle its own copy of the allocator (instead of storing it just once) means wasting 16 bytes per ArrayList. The allocator-less variant is simply more flexible in that regard.
Comment · 1 month ago
In the Zig core team we have the right to decide how we want to conduct the development of our open source project, and that decision is based in good part on the same factors presented in this post, which are significantly more important than validating your FOMO.
Likewise, in your projects you can do whatever you want. That was true before LLMs and is just as true now. Thinking otherwise is a weird form of open source kleptomania induced by listening to too many techfluencers, in my opinion :^)
In my open source projects I decide which tasks I'm willing to delegate and which tasks I want to take on myself and, of those that I'm willing to delegate, I decide who gets to take on them. This includes the fact that, even if the quickest way to get something done is to delegate it to an LLM, if I want to do it myself for personal growth, I will still do it myself.
Conversely, it should go without saying that if I want to use LLMs, that's my right and whoever wants to complain can go fork (the repo) themselves.
Comment · 3 months ago
(reposting my comment from lobsters)
For anybody reading, the project tracks new Zig to get all the new async I/O goodies but was hit by some regressions in Zig's translate-c because it recently became fully independent from LLVM.
Other contributors and I took this as an opportunity to contribute some fixes to translate-c and in my case I also switched for a bit to my other projects, mainly https://zine-ssg.io, which I had neglected for a few months while going all-in on awebo.
I plan to resume development of awebo in a month or two, I just want to leave Zine in a good spot before switching again (I have a bad time paging between different projects too often and prefer doing continuous work for a while before switching back).
Comment · 3 months ago
Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
Comment · 3 months ago
The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.
Comment · 3 months ago
To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.
To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
Comment · 3 months ago
That is a 100% on point analysis, there was a lot of hype around Bun since the beginning when it was an invite only project. Arguably that same interest is what got Jarred VC funding in the first place.
Note that usage and public interest are not the same quantity, people also care about the potential of a project.
Zig Livecoding: https://twitch.tv/kristoff_it YouTube: https://youtube.com/@ZigSHOWTIME Blog: https://kristoff.it
I curate Software You Can Love: https://softwareyoucan.love