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.

> 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.

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

It really feels like Firefox is not a supported browser on GitHub, I hit this and also find that much of the time the commit message is not correctly pulled from the PR description when that setting is enabled

Given I get "Too Many Requests" if I try and search for a repo from FF logged out and have done for at least a year, I'd say so.

Works fine on Chrome/Edge.

Meanwhile, bitbucket has never given us problems with several of our team using Firefox

My alma mater, Ursinus, is a very small school and has few claims to fame; but one of them is that John Mauchly taught there before going to Penn to design ENIAC. Wikipedia puts it bluntly:

> Mauchly's teaching career truly began in 1933 at Ursinus College where he was appointed head of the physics department, where he was, in fact, the only staff member.

OKPalette by David Aerne is my favorite tool for this, it chooses points sensibly but then also lets you drag around or change the number of colors you want: https://okpalette.color.pizza/

You’re in luck, he sells it as a book: https://www.amazon.com/Gervais-Principle-Complete-Office-Rib...

For me, it's file system latency on mac os when virtualizing that kills me. Cargo, npm, pip, etc create many small files and there's a high per-file latency on the FS layer

I've built tools with both Go and Rust as LLM experiments, and it is a real advantage for Go that the test/compile cycle is much faster.

I've been successful with each, I think there's positives and negatives to both, just wanted to mention that particular one that stands out as making it relatively more pleasant to work with.

> who has a js engine that is both fast and embeds well? nobody

Fabrice Bellard! https://github.com/bellard/mquickjs

(I agree with you, just wanted to note this super neat project)

quickjs/mquickjs are good at embedding but nowhere close to luajit in terms of speed. (i have some experience with quickjs https://github.com/justjake/quickjs-emscripten)

as an aside i’m curious how quickjs/mquickjs compares to mruby in speed and size. something to ponder

I created one I like: https://github.com/llimllib/mdriver

it can echo images with kitty image protocol, and streams the output, which I use to show LLM output as it arrives

It doesn't handle paging - you can pipe it to `less` or whatever pager for that

Not OP, but I use ripgrep and customize it with an alias as well, so it applies equally there