Earlier quoted context omitted.
I'm about to release some tooling that's been very effective for me. Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code. We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone). The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the…
You forgot to include link to your tool.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
161–170 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#162Earlier quoted context omitted.
> Not writing code anymore. If you were an L6+, it was already not really about that. It's kind of amazing to me that people think the only thing engineers do and the only value they bring is writing code.
I have no idea what an l6 is, is this a big corp rat race thing?
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#163Earlier quoted context omitted.
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 ev…
> TLDR; The Zig compiler takes about 1 minute and 30 seconds to compile debug builds of Bun. Zig's language server doesn't do basic things like type-checking, so often have to run the compiler to see if my code works. 90 seconds to less than 1 second. That's astonishing
I expect it to drop to 300ms once it no longer relies on Mold for linking. Zig's experimental linker can just modify the binary in place.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#164Earlier quoted context omitted.
You should give the article[0] a read. "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide." "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,00…
That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used. Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding ag…
> But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.
agreed. in my side project im tinkering with a memory safety checker in zig that intercepts a compiler artifact, and it works better with idiomatic zig, problematic code is when you try to write c-isms in zig -- so i basicallt tell the checker to reject c-isms that create ambiguity for safety checking.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#165Earlier quoted context omitted.
I'm about to release some tooling that's been very effective for me. Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code. We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone). The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the…
Can you elaborate on the tests thing? I'm new to testing, and AI agents recently voluntarily added an large number of tests to one of my projects. I've been learning a lot by reading them, and it seems like a great habit to develop. But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own ju…
i find that the easiest way to make sure you have robust tests is to do strict red/green cycles for each feature and bugfix in your codebase.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#166Earlier quoted context omitted.
I'm assuming based on the special unicode angled quote marks that this is copy/pasted from an AI? I don't understand why people would type a lot more into an AI just to copy a comment this short, which would be at least 10x faster to just type by hand.
Not sure about op but if I post here from my phone I get those. Example: “quoted string”
huh interesting, I've never realized this, is it iOS or android?
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#167> To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. How long has this person been programming?
Over a decade. I should've clarified, I meant "trivially dead" code that's not called by anything. Can you think of another project with that much?
I don't contribute to open source projects often but deleting dead code has never been a big priority in any project I've worked on unless it's creating real technical debt or it's something easy clean up as part of a bigger migration (similar to what you did here). The point is you had time to look at that stuff and take the risk of deleting it while big projects have a hundred other priorities on Github Issues and customer complaints.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#168Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#169Earlier quoted context omitted.
> Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is.
Well, do one thing an one thing good as in Unix philosophy? - Runtime - Package manager - Test runner - Build tool
The unix philosophy pertained to simple composable limited cli tools. Most of which, at least the initial bunch, where written by the same handful of people, too, and one of each only: no several competing programs to awk and grep and cut and so on with widely different philosophies. At worst you had e.g. different implementations (like Sys V vs BSD vs GNU), and even that was already bad enough.
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
At the worst case you get this: https://xkcd.com/1987/
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#170Earlier quoted context omitted.
> Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is.
Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
>Why? Is fewer things always better?
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/
>Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Taking it to an extreme, why not?
If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with.
Go got quite close with that.