How does bun compare with upcoming Vite+?
We sped up bun by 100x
21–30 of 68 posts
Re: We sped up bun by 100x
#22Seems like they actually sped bun up ~1x: When evaluating the complete bun install improvements, it came out speed-wise to about the same as the existing git usage (due to networking being the big bottleneck time-wise despite more cases being slightly faster with ziggit over multiple benchmarks). Except, it's done in 100% zig and those internal improvements pile up as projects consist of more git dependencies. All in…
You have to maintain a completely separate implementation of AI generated code that's translated from C, so not even idiomatic zig.
Edit And then I go their repository and read commits like this https://github.com/hdresearch/ziggit/commit/31adc1da1693e402... which confirms it wasn't even looked over by a human.
Re: We sped up bun by 100x
#23Zig is a well-kept secret for writing highly efficient WebAssembly modules.
Re: We sped up bun by 100x
#24>it becomes possible to see upward of 100x speedups for some git operations.
They really stretch the limits of an honest title there.
Re: We sped up bun by 100x
#25So, they implemented a git client in zig, that had some significant speedups for their usecase. However: > The git CLI test suite consists of 21,329 individual assertions for various git subcommands (that way we can be certain ziggit does suffice as a drop-in replacement for git). > While we only got through part of the overall test suite, that's still the equivalent of a month's worth of straight developer work (aga…
Wait, so they don’t have test parity with git? How do they know that they, umm … did the actual thing they were trying to do?
I have heard that you can speed up your favorite compression algorithm by 1000x, if you are not so concerned about what happens when you try to decompress it.
Re: We sped up bun by 100x
#26Seems like they actually sped bun up ~1x: When evaluating the complete bun install improvements, it came out speed-wise to about the same as the existing git usage (due to networking being the big bottleneck time-wise despite more cases being slightly faster with ziggit over multiple benchmarks). Except, it's done in 100% zig and those internal improvements pile up as projects consist of more git dependencies. All in…
> maintain a separate git implementation
If git were a rapidly evolving project then I'd think this'd be a stronger issue.
With git being more of an established protocol that projects can piggy-back off of from GitHub to jj, filling a library in a new language seems like something that contributes
Re: We sped up bun by 100x
#27Earlier quoted context omitted.
Wait, so they don’t have test parity with git? How do they know that they, umm … did the actual thing they were trying to do?
I have heard that you can speed up your favorite compression algorithm by 1000x, if you are not so concerned about what happens when you try to decompress it.
Also gotta love the write-only disk as a hardware analogy. Insane write speeds and infinite capacity...
Re: We sped up bun by 100x
#28AI slop with your usual hallucinated unrealistic speedups claims
yawn immediate skip
Re: We sped up bun by 100x
#29So, they implemented a git client in zig, that had some significant speedups for their usecase. However: > The git CLI test suite consists of 21,329 individual assertions for various git subcommands (that way we can be certain ziggit does suffice as a drop-in replacement for git). > While we only got through part of the overall test suite, that's still the equivalent of a month's worth of straight developer work (aga…
Wait, so they don’t have test parity with git? How do they know that they, umm … did the actual thing they were trying to do?
I ran the test suite specifically for git's CLI as that was the target I wanted to build towards (Anthropic's C compiler failed to make an operating system since that was never in their original prompts/goals)
The way it gets organized is there are "scripts" which encompass different commands (status, diff, commit, etc) however each of these scripts themselves contain several hundred distinct assertions covering flags and arguments.
The test suite was my way of validating I not only had a feature implemented but also "valid" by git's standards
Re: We sped up bun by 100x
#30So, they implemented a git client in zig, that had some significant speedups for their usecase. However: > The git CLI test suite consists of 21,329 individual assertions for various git subcommands (that way we can be certain ziggit does suffice as a drop-in replacement for git). > While we only got through part of the overall test suite, that's still the equivalent of a month's worth of straight developer work (aga…
Reminds me when I was happy with my algorithm being super fast until I started tackling edge cases. Suddenly it's got quite slow.
Edge cases certainly apply with scripts depending on specific git CLI args or stdout strings may not suffice with ziggit.
_However_, for the use cases that most developers or agents are looking for, ziggit should have enough features covered. Happy to fix issues or bugs if that's not the case