kristoff_it

8 ms·

1.
Who Should Pay for Source Code Availability?(kristoff.it)
4 points by kristoff_it 1mo ago|0 comments
2.
Who Should Pay for Source Code Availability?(kristoff.it)
4 points by kristoff_it 1mo ago|0 comments
3.
Who Should Pay for Source Code Availability?(kristoff.it)
3 points by kristoff_it 1mo ago|0 comments
4.
Who Should Pay for Source Code Availability?(kristoff.it)
20 points by kristoff_it 1mo ago|0 comments
5.
by kristoff_it 2mo 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.
6.
by kristoff_it 2mo 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.
7.
by kristoff_it 2mo 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.
8.
by kristoff_it 2mo 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 l
9.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds(ziggit.dev)
305 points by kristoff_it 2mo ago|191 comments
10.
by kristoff_it 2mo 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 a
11.
My thoughts on the Bun Rust rewrite(andrewkelley.me)
817 points by kristoff_it 2mo ago|707 comments
12.
Returning to Zig(gracefulliberty.com)
5 points by kristoff_it 3mo ago|0 comments
13.
by kristoff_it 3mo ago
> Writing memory safe code in unsafe languages requires global reasoning If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty m
14.
by kristoff_it 3mo ago
Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ
15.
by kristoff_it 3mo ago
I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software. I posted this link at the same time when I posted it to Lobsters ( https://lobste.rs/s
16.
by kristoff_it 3mo ago
The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarre
17.
by kristoff_it 3mo ago
> I imagine it's a difficult time to be a Zig developer. In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into
18.
by kristoff_it 3mo ago
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post i
19.
by kristoff_it 3mo ago
trying to make good software :^)
20.
by kristoff_it 3mo ago
That is the opposite of what's going on, read this https://kristoff.it/blog/contributor-poker-and-ai/
21.
by kristoff_it 3mo ago
The problem statement is clear to everybody. > For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time
22.
by kristoff_it 4mo ago
Another Zig GUI project that people might be interested in is DVUI: https://github.com/david-vanderson/dvui
23.
My Software North Star(kristoff.it)
220 points by kristoff_it 4mo ago|155 comments
24.
by kristoff_it 4mo ago
It's not Future.await that is special per se, it's that it (Future.await) will have in it somewhere either in its body or in another function that it calls in turn, a use of `suspend` (using old Zig syntax). `suspend` is the keywo
25.
by kristoff_it 4mo ago
None of it, we've been working on this stuff for a long time already, scroll the devlog backwards, you will find plenty of entries on that topic. It's the opposite: people have become more receptive to communication about this wor
26.
by kristoff_it 4mo ago
> If so, does that mean that every function in zig is a stackless coroutine? No and yes. If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex. If you
27.
Zig ELF Linker Improvements Devlog(ziglang.org)
227 points by kristoff_it 4mo ago|102 comments
28.
by kristoff_it 4mo ago
A vtable indirection is essentially free when you're going to perform a syscall. What matters is that the buffer is above the vtable (which is already the case for the current implementation) so that you don't pay for the indirect
29.
by kristoff_it 4mo ago
> You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. I think that's a neat idea, but in the reverse: do as much as you can in the lower level langua
30.
by kristoff_it 4mo ago
Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists. In any case Bun has already committed to the Rust slop switch, so it doesn&#x

More ›