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 all, it seems like a sensible upstream contribution.
So you have to maintain a completely separate git implementation and keep that up to date with upstream git, all for the benefit of being indistinguishable on benchmarks. Oh well!
The commit I linked shows that it didn't even read the user name and email from git's config file, but used a test name, which means it's woefully incomplete.
It's just one giant function. Sometimes big functions are necessary. This one is clearly AI generated and not very readable for a human. This is just from a quick glance.
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
Now we just need that AI booster guy to join this thread and tell us that actually this is super impressive. He was doing that for that worthless “browser” that Cursor built.
These "AI rewrite" projects are beginning to grate on me.
Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. However, if the original package is in its training data, it's very likely to plagiarize the original source.
Also, who actually wants to use or maintain a large project that no one understands and that doesn't have a documented history of thoughtful architectural decisions and the context behind them? No matter how tightly you structure AI work, probabilistic LLM logorrhea cannot reliably adopt or make high-level decisions/principles, apply them, or update them as new data arrives. If you think otherwise, you're believing an illusion - truly.
A large software project's source code and documentation are the empirical ground-truth encoding of a ton of decisions made by many individuals and teams -- decisions that need to be remembered, understood, and reconsidered in light of new information. AI has no ability to consider these types of decisions and their accompanying context, whether they are past, present, or future -- and is not really able to coherently communicate them in a way that can be trusted to be accurate.
That's why I can't and won't trust fully AI-written software beyond small one-off-type tools until AI gains two fundamentally new capabilities:
(1) logical reasoning that can weigh tradeoffs and make accountable decisions in terms of ground-truth principles accurately applied to present circumstances, and
(2) ability to update those ground-truth principles coherently and accurately based on new, experiential information -- this is real "learning"
> Sure, if you have a complete test suite for a library or CLI tool
And this is a huge "if". Having 100% test coverage does not mean you've accounted for every possible edge or corner case. Additionally, there's no guarantee that every bugfix implemented adequate test coverage to ensure the bug doesn't get reintroduced. Finally, there are plenty of poorly written tests out there that increase the test coverage without actually testing anything.
This is why any sort of big rewrite carries some level of risk. Tests certainly help mitigate this risk, but you can never be 100% sure that your big rewrite didn't introduce new problems. This is why code reviews are important, especially if the code was AI generated.
> Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement.
This was the "validation" used for determining how much progress was made at a given point in time. Re training data concerns, this was done and shipped to be open source (under GPLv2) so there's no abuse of open source work here imo
Re the tradeoffs you highlight - these are absolutely true and fair. I don't expect or want anyone to just use ziggit because it's new. The places where there performance gains (ie internally with `bun install` or as a better WASM binary alternative) are places that I do have interest or use in myself
_However_, if I could interest you in one thing. ziggit when compiled into a release build on my arm-based Mac, showed 4-10x faster performance than git's CLI for the core workflows I use in my git development
I suppose "Project X has been used productively by Y developers for Z amount of time" is a decent-enough endorsement (in this case, ziggit used by you).
But after the massive one-off rewrite, what are the chances that (a) humans will want to do any personal effort on reading it, documenting it, understanding it, etc., or that (b) future work by either agents or humans is going to be consistently high-quality?
Beyond a certain level of complexity, "high-quality work" is not just about where a codebase is right now, it's where it's going and how much its maintainers can be trusted to keep it moving in the right direction - a trust that only people with a name, reputation, observable values/commitments, and track record can earn.
So, 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).
<snip>
> 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 (again, without sleep or eating factored in).
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.
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
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
> _However_, for the use cases that most developers or agents are looking for
What use cases are those? How did you determine that these are the use cases most developers/agents are looking for?
For me, git has a ton of features that I rarely use. But when I need them, I really need them. Any replacement that doesn't cover these edge cases is fundamentally incomplete and insufficient, even if it works fine 99% of the time.
> The bun team has already tested using git's C library and found it to be consistently slower hence resorting to literally executing the git CLI when performing bun install.
I find that to be a much more remarkable claim. Git doesn't have a C library, and even if it did, In which world is literally shelling out faster than a C library call? I suppose libgit2 could be implemented poorly.
If we follow their link[1] we get some clarity. It's an markdown (ai prompt?) file which just states it. Apparently they've "microbenchmarked" creating new git repositories. I really wonder if creating new git repositories is really on their hot path, but whatever.
Where does that claim in that random markdown file come from then? Well apparently, 3 years ago when somebody was "restructuring docs"[2] and just made it up.
I guess there really is a class of "engineers" that the AI can replace.
libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library.
referencing the commit where they removed the ability to link with libgit2 because it was slower.
Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.
I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.
I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality
As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done
> Your comment does not seem to be in good faith, implying that they've made up the performance difference.
I believe I have accurately represented what the article says. Had the article provided the comment you have just linked, I would have commented on that as well. I did not intend to imply that they manufactured the performance difference, merely that they don't know what they are talking about. The thought I have in my head is that they are incompetent, not that they are malicious.
I wholeheartedly agree that libgit2 is full of footguns, that's why it matters that it's not actually "git's own C library" but a separate project. I also agree that you usually end up shelling out to git, exactly because of those problems libgit2 has. If those problems aren't speed though, and I don't think they are, the blog post would have to cover how this reimplementation of libgit2 avoids those problems.
I'm not here to litigate if bun would be faster with libgit2. I am however here to make the argument that the blogpost does not make a convincing argument for why libgit2 isn't good enough.
Bun's attempted to integrate with libgit2 instead of spawning calls to the git CLI and found it to be consistently 3x slower iirc
The micro-benchmarks are for the internal git operations that bun rn delegates to CLI calls. Overall, network time (ie round trip to GitHub and back) is what balances the performance when evaluating `bun install` but there are still places where ziggit has better visible wins like on arm-based Macs https://github.com/hdresearch/ziggit/blob/master/BENCHMARKS....
I don't know what that "BENCHMARKS" document is supposed to show. When I try to replicate their results I'm getting wildly faster executions of standard git, and they don't provide enough details for me to theorize why.
I also noticed that their version of the "blame src/main.zig" command doesn't actually work (it shows all lines as not being committed). Sure, it's easy to optimize an algorithm if you just don't do the work. Git does indeed take longer, but at least it actually gives you a blame of the file.
The dark mode looks better. In the light mode they have to improve the contrast. The lines in the visualisations are almost invisible, also the data table on the left
Yeah. I was going to suggest Firefox Reader Mode, but it fails miserably on this particular site for some reason. Ublock Origin's "disable remote fonts", still works great on this site though.
I think we might be getting to the point where submissions for projects that are primarily written by ai and/or ai agents need to be tagged with [agent] in the title
If this were 2+ years ago perhaps, with industry adopting more agents in their SDLCs (ie Stripe minions or Ramp background agents), I think we're more a matter of time before we treat agent/human built products the same unless we're branding smth as artisanal human-crafted software
With the recent barrage of AI-slop 'speedup' posts, the first thing I always do to see if the post is worth a read is doing a Ctrl+F "benchmark" and seeing if the benchmark makes any fucking sense.
99% of the time (such as in this article), it doesn't. What do you mean 'cloneBare + findCommit + checkout: ~10x win'? Does that mean running those commands back to back result in a 10x win over the original? Does that mean that there's a specific function that calls these 3 operations, and that's the improvement of the overall function? What's the baseline we're talking about, and is it relevant at all?
Those questions are partially answered on the much better benchmark page[1], but for some reason they're using the CLI instead of the gitlib for comparisons.
The reason being bun actually tested both using the git CLI as well as libgit2. Across the board the C library was 3x slower than just spawning calls to the git CLI.
Under the hood, bun's calling these operations when doing a `bun install` and these are the places where integrating 100% gives the most boost. When more and more git deps are included in a project, these gains pile up.
However, the results appear more at 1x parity when accounting for network times (ie round trip to GitHub)
If they pulled off a 10x gain across sequential git ops, the post should show flame graphs or profiler output and spell out whether that label is one path or three separate calls run back to back, because 'cloneBare + findCommit + checkout' says almost nothing on its own. I read it as marketing copy.
What it cost doesn't actually say what it cost. I wonder what models they used. Napkin math of Opus for everything (probably not true) with no caching suggests $67,000.
They mention Anthropic, so I assumed something similar. At $5 per 5 million tokens, 13 billion would cost $65,000. However, the image in the article shows over 17 billion used, which is $85,000. That's an entry-level programmer's yearly salary. It doesn't quite pass their code tests, and it's automatic code translation, so it's going to be a pretty direct transcription. There's still probably a lot of messy code to clean up. I'm not sure it's worth it.
im pretty stoked about the llm harness theyre using. cause I wrote all the code thats not monopi code in that fork!
despite it’s paucity of features, the changes i landed in it from my design notes actually have been so smooth in terms of comparative ux/ llm behavior that its my daily driver since ive stood it up.
Previously, since early december, ive had to run a patch script on every update of claude code to make it stop undermining me. I didnt need a hilarious code leak to find the problematic strings in the minified js ;)
I regard punkin-pi as a first stab at translating ideas ive had over the past 6 months for reliable llm harnesses. I hit some walls in terms of mono pi architecture for doing much more improvement with mono pi.
so Im working on the next gen of agent harnesses! stay tuned!
The title is obviously dishonest. I do not hesitate to call it a lie.
The post is also not about the speed increase, it's about how proud this team is of their agent orchestration scheme.
As I understand it, there is really no speed difference at all between Zig and C, just some cognitive overhead associated with doing things "right" in C. It's all machine code at bottom.
So why is this rewrite faster? Why did the authors choose Zig? How has the logic or memory management changed?
The authors give us absolutely no insight whatsoever into the the Zig code. No indication that they know anything about Zig, or systems programming, at all. I wish this was an exaggeration.
And really. With all this agentic power at your fingertips, why wouldn't they just contribute these improvements to git itself? I can think of at least one reason, that they don't want their changes to be rejected as unhelpful or low-quality.
100x is a bold claim but the Zig approach to optimizing hot paths in Bun makes a lot of sense. There is so much low hanging fruit when you actually dig into how package managers interact with git under the hood. Nice writeup, the before/after benchmarks are convincing.
But then there's this: "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 all, it seems like a sensible upstream contribution."
Sooo, after burning these 10k+ worth of tokens we find out that it's sensible to use it because the language (zig) feels good as opposed to git itself which now has +20 years of human eval on it. That seems. Well. Yeah...
The original target was bun since it itself is written in zig, not because of anything specific to the language
When it was clear that there were benefits in filling in more of git's capabilities (ie targeting WASM), I then went and filled in more git features.
It's not by any means a universal win over everything but it does have notable wins like having git operations be between 4-10x faster on arm-based MacBooks than git itself
Seems like they actually sped bun up ~1x:
So you have to maintain a completely separate git implementation and keep that up to date with upstream git, all for the benefit of being indistinguishable on benchmarks. Oh well!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.
This was orchestrated and developed by agents with verifications like the codebase compiling or git's CLI test suite passing.
That was so the commit authors don't all appear like blank accounts on GitHub
I don't know zig well. What's raising flags for you?
The commit I linked shows that it didn't even read the user name and email from git's config file, but used a test name, which means it's woefully incomplete.
Then there's stuff like this: https://github.com/hdresearch/ziggit/blob/master/src/cmd_bra...
It's just one giant function. Sometimes big functions are necessary. This one is clearly AI generated and not very readable for a human. This is just from a quick glance.
> 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
Now we just need that AI booster guy to join this thread and tell us that actually this is super impressive. He was doing that for that worthless “browser” that Cursor built.
These "AI rewrite" projects are beginning to grate on me.
Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. However, if the original package is in its training data, it's very likely to plagiarize the original source.
Also, who actually wants to use or maintain a large project that no one understands and that doesn't have a documented history of thoughtful architectural decisions and the context behind them? No matter how tightly you structure AI work, probabilistic LLM logorrhea cannot reliably adopt or make high-level decisions/principles, apply them, or update them as new data arrives. If you think otherwise, you're believing an illusion - truly.
A large software project's source code and documentation are the empirical ground-truth encoding of a ton of decisions made by many individuals and teams -- decisions that need to be remembered, understood, and reconsidered in light of new information. AI has no ability to consider these types of decisions and their accompanying context, whether they are past, present, or future -- and is not really able to coherently communicate them in a way that can be trusted to be accurate.
That's why I can't and won't trust fully AI-written software beyond small one-off-type tools until AI gains two fundamentally new capabilities:
(1) logical reasoning that can weigh tradeoffs and make accountable decisions in terms of ground-truth principles accurately applied to present circumstances, and
(2) ability to update those ground-truth principles coherently and accurately based on new, experiential information -- this is real "learning"
> Sure, if you have a complete test suite for a library or CLI tool
And this is a huge "if". Having 100% test coverage does not mean you've accounted for every possible edge or corner case. Additionally, there's no guarantee that every bugfix implemented adequate test coverage to ensure the bug doesn't get reintroduced. Finally, there are plenty of poorly written tests out there that increase the test coverage without actually testing anything.
This is why any sort of big rewrite carries some level of risk. Tests certainly help mitigate this risk, but you can never be 100% sure that your big rewrite didn't introduce new problems. This is why code reviews are important, especially if the code was AI generated.
> Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement.
This was the "validation" used for determining how much progress was made at a given point in time. Re training data concerns, this was done and shipped to be open source (under GPLv2) so there's no abuse of open source work here imo
Re the tradeoffs you highlight - these are absolutely true and fair. I don't expect or want anyone to just use ziggit because it's new. The places where there performance gains (ie internally with `bun install` or as a better WASM binary alternative) are places that I do have interest or use in myself
_However_, if I could interest you in one thing. ziggit when compiled into a release build on my arm-based Mac, showed 4-10x faster performance than git's CLI for the core workflows I use in my git development
I suppose "Project X has been used productively by Y developers for Z amount of time" is a decent-enough endorsement (in this case, ziggit used by you).
But after the massive one-off rewrite, what are the chances that (a) humans will want to do any personal effort on reading it, documenting it, understanding it, etc., or that (b) future work by either agents or humans is going to be consistently high-quality?
Beyond a certain level of complexity, "high-quality work" is not just about where a codebase is right now, it's where it's going and how much its maintainers can be trusted to keep it moving in the right direction - a trust that only people with a name, reputation, observable values/commitments, and track record can earn.
So, 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).
<snip>
> 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 (again, without sleep or eating factored in).
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...
It's just a lossy compression scheme.
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
This is the same as all the folks asking for and hawking quantized models.
It doesn't matter if the parent model is GPT GOD mode mythos opus 100x Ultra. What matters is the performance of the quantized model.
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
> _However_, for the use cases that most developers or agents are looking for
What use cases are those? How did you determine that these are the use cases most developers/agents are looking for?
For me, git has a ton of features that I rarely use. But when I need them, I really need them. Any replacement that doesn't cover these edge cases is fundamentally incomplete and insufficient, even if it works fine 99% of the time.
> The bun team has already tested using git's C library and found it to be consistently slower hence resorting to literally executing the git CLI when performing bun install.
I find that to be a much more remarkable claim. Git doesn't have a C library, and even if it did, In which world is literally shelling out faster than a C library call? I suppose libgit2 could be implemented poorly.
If we follow their link[1] we get some clarity. It's an markdown (ai prompt?) file which just states it. Apparently they've "microbenchmarked" creating new git repositories. I really wonder if creating new git repositories is really on their hot path, but whatever.
Where does that claim in that random markdown file come from then? Well apparently, 3 years ago when somebody was "restructuring docs"[2] and just made it up.
I guess there really is a class of "engineers" that the AI can replace.
[1]: https://github.com/oven-sh/bun/blob/3ed4186bc8db8357c670307f... [2]: https://github.com/oven-sh/bun/commit/011e157cac7698050370e2...
libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library.
Your comment does not seem to be in good faith, implying that they've made up the performance difference. There's a comment with a benchmark here: https://github.com/oven-sh/bun/blob/4760d78b325b62ee62d6e47b...
referencing the commit where they removed the ability to link with libgit2 because it was slower.
Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.
I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.
I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality
As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done
> Your comment does not seem to be in good faith, implying that they've made up the performance difference.
I believe I have accurately represented what the article says. Had the article provided the comment you have just linked, I would have commented on that as well. I did not intend to imply that they manufactured the performance difference, merely that they don't know what they are talking about. The thought I have in my head is that they are incompetent, not that they are malicious.
I wholeheartedly agree that libgit2 is full of footguns, that's why it matters that it's not actually "git's own C library" but a separate project. I also agree that you usually end up shelling out to git, exactly because of those problems libgit2 has. If those problems aren't speed though, and I don't think they are, the blog post would have to cover how this reimplementation of libgit2 avoids those problems.
I'm not here to litigate if bun would be faster with libgit2. I am however here to make the argument that the blogpost does not make a convincing argument for why libgit2 isn't good enough.
Bun's attempted to integrate with libgit2 instead of spawning calls to the git CLI and found it to be consistently 3x slower iirc
The micro-benchmarks are for the internal git operations that bun rn delegates to CLI calls. Overall, network time (ie round trip to GitHub and back) is what balances the performance when evaluating `bun install` but there are still places where ziggit has better visible wins like on arm-based Macs https://github.com/hdresearch/ziggit/blob/master/BENCHMARKS....
I don't know what that "BENCHMARKS" document is supposed to show. When I try to replicate their results I'm getting wildly faster executions of standard git, and they don't provide enough details for me to theorize why.
I also noticed that their version of the "blame src/main.zig" command doesn't actually work (it shows all lines as not being committed). Sure, it's easy to optimize an algorithm if you just don't do the work. Git does indeed take longer, but at least it actually gives you a blame of the file.
Only 1.3x speed despite not working lol
Amazing what agents can achieve
Aside: That font is really hard on my eyes. Anyone else?
The dark mode looks better. In the light mode they have to improve the contrast. The lines in the visualisations are almost invisible, also the data table on the left
https://vers.sh/hdr_legacy/images/manager_vs_manager_of_mana...
Yeah. I was going to suggest Firefox Reader Mode, but it fails miserably on this particular site for some reason. Ublock Origin's "disable remote fonts", still works great on this site though.
I cross-posted to my personal blog too https://yev.bar/ziggit
Me as well. Calling it painful would be overstating it, but it's not pleasant.
I think we might be getting to the point where submissions for projects that are primarily written by ai and/or ai agents need to be tagged with [agent] in the title
If this were 2+ years ago perhaps, with industry adopting more agents in their SDLCs (ie Stripe minions or Ramp background agents), I think we're more a matter of time before we treat agent/human built products the same unless we're branding smth as artisanal human-crafted software
Well, we're not there today. Generated code and prose are still trivial to spot.
And even mass-produced products benefit from thoughtful design by a human.
Why didn't the blog post explain anything about why the rewrite is faster? Or about Zig, or C, programming, at all?
With the recent barrage of AI-slop 'speedup' posts, the first thing I always do to see if the post is worth a read is doing a Ctrl+F "benchmark" and seeing if the benchmark makes any fucking sense.
99% of the time (such as in this article), it doesn't. What do you mean 'cloneBare + findCommit + checkout: ~10x win'? Does that mean running those commands back to back result in a 10x win over the original? Does that mean that there's a specific function that calls these 3 operations, and that's the improvement of the overall function? What's the baseline we're talking about, and is it relevant at all?
Those questions are partially answered on the much better benchmark page[1], but for some reason they're using the CLI instead of the gitlib for comparisons.
[1] https://github.com/hdresearch/ziggit/blob/5d3deb361f03d4aefe...
The reason being bun actually tested both using the git CLI as well as libgit2. Across the board the C library was 3x slower than just spawning calls to the git CLI.
Under the hood, bun's calling these operations when doing a `bun install` and these are the places where integrating 100% gives the most boost. When more and more git deps are included in a project, these gains pile up.
However, the results appear more at 1x parity when accounting for network times (ie round trip to GitHub)
If they pulled off a 10x gain across sequential git ops, the post should show flame graphs or profiler output and spell out whether that label is one path or three separate calls run back to back, because 'cloneBare + findCommit + checkout' says almost nothing on its own. I read it as marketing copy.
What it cost doesn't actually say what it cost. I wonder what models they used. Napkin math of Opus for everything (probably not true) with no caching suggests $67,000.
Cool article though!
They mention Anthropic, so I assumed something similar. At $5 per 5 million tokens, 13 billion would cost $65,000. However, the image in the article shows over 17 billion used, which is $85,000. That's an entry-level programmer's yearly salary. It doesn't quite pass their code tests, and it's automatic code translation, so it's going to be a pretty direct transcription. There's still probably a lot of messy code to clean up. I'm not sure it's worth it.
Anthropic owns Bun, so they presumably did not directly pay for anything.
im pretty stoked about the llm harness theyre using. cause I wrote all the code thats not monopi code in that fork!
despite it’s paucity of features, the changes i landed in it from my design notes actually have been so smooth in terms of comparative ux/ llm behavior that its my daily driver since ive stood it up.
Previously, since early december, ive had to run a patch script on every update of claude code to make it stop undermining me. I didnt need a hilarious code leak to find the problematic strings in the minified js ;)
I regard punkin-pi as a first stab at translating ideas ive had over the past 6 months for reliable llm harnesses. I hit some walls in terms of mono pi architecture for doing much more improvement with mono pi.
so Im working on the next gen of agent harnesses! stay tuned!
Is this more vibe-coded garbage?
with a different git client
https://news.ycombinator.com/item?id=47618895 to discuss the git implementation
How does bun compare with upcoming Vite+?
Upcoming?
This blog post calls libgit2 "git's C library" as if it is in any way related to git. I don't think it is.
Long-ass LLM write-up that repeats itself several times, i couldn't finish reading.
Big if true, etc
>it becomes possible to see upward of 100x speedups for some git operations.
They really stretch the limits of an honest title there.
So uh.. about that sentence where it says you only pass part of the test suite...
Zig is a well-kept secret for writing highly efficient WebAssembly modules.
The title is obviously dishonest. I do not hesitate to call it a lie.
The post is also not about the speed increase, it's about how proud this team is of their agent orchestration scheme.
As I understand it, there is really no speed difference at all between Zig and C, just some cognitive overhead associated with doing things "right" in C. It's all machine code at bottom.
So why is this rewrite faster? Why did the authors choose Zig? How has the logic or memory management changed?
The authors give us absolutely no insight whatsoever into the the Zig code. No indication that they know anything about Zig, or systems programming, at all. I wish this was an exaggeration.
And really. With all this agentic power at your fingertips, why wouldn't they just contribute these improvements to git itself? I can think of at least one reason, that they don't want their changes to be rejected as unhelpful or low-quality.
AI slop with your usual hallucinated unrealistic speedups claims
yawn immediate skip
[dead]
100x is a bold claim but the Zig approach to optimizing hot paths in Bun makes a lot of sense. There is so much low hanging fruit when you actually dig into how package managers interact with git under the hood. Nice writeup, the before/after benchmarks are convincing.
But then there's this: "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 all, it seems like a sensible upstream contribution."
Sooo, after burning these 10k+ worth of tokens we find out that it's sensible to use it because the language (zig) feels good as opposed to git itself which now has +20 years of human eval on it. That seems. Well. Yeah...
The original target was bun since it itself is written in zig, not because of anything specific to the language
When it was clear that there were benefits in filling in more of git's capabilities (ie targeting WASM), I then went and filled in more git features.
It's not by any means a universal win over everything but it does have notable wins like having git operations be between 4-10x faster on arm-based MacBooks than git itself