Can Bundler Be as Fast as uv?

Wow, we have different experiences.

Dunno, I've been working on very large monoliths for ages now. Previous company was in the 800 gems. But aside from the very first setup on when upgrading Ruby I never install from scratch so it's always fast enough that I don't feel like I need to alt-tab and do something else.

or the lack of caching in the CIs/Dockerfiles I tend to see.

That indeed can be brutal on large gemfiles, but even if it was close to instant you'd definitely want to cache that.

something as (seemingly) obvious

Yeah, but even just realizing this is happening takes a while. The rubygems/bundler codebase is pretty hard to work with. Over the years I have made contributions to several hundreds libraries, even to Ruby itself, but the dozen or so time I tried to fix something simple in Bundler I ended up giving up after banging my head against my desk for hours.

I deleted my comment because I posted something factually incorrect and couldn't edit it. Here's the same comment updated.

Bundler has actual funding, right?

Hi. I'm on the Ruby central open source committee that oversees the OSS budget. Ruby Together managed bundler funding for years and merged with Ruby Central (who has managed the rubygems.org service).

It's operated that way for a few years and I would say there has been turmoil and dysfunction (though I've never met an org that didn't have some).

I just started the role, but funding mostly has worked like this: There's a set oncall amount per month and in an addition there is a pool of hours that are made available to select maintainers that they can then bill. Like "you have 20 hours this month." In looking at this past year, some funds have gone to feature work, also funds have been billed for reviewing PRs and merging them. But it's not limited to just bundler work, it could also be open to operational/service work (like upgrading a database) or spending time on another rubygems org repo. Individuals are responsible for tracking their time, and then they submit for funding reimbursement. All hours are paid the same flat rate.

With this funding mechanism, maintainers are free to coordinate with themselves, schedule themselves, and invest time where they see fit. This created a bit of an insular group and also encouraged them to prioritize each other's work over community contributions (signing off on someone else’s paid work is easier than coaching an external contribution). It has high freedom and autonomy for the maintainers who are in the circle, but produced low accountability for Ruby Central (which has lost grants after sponsors did not feel their money was being well spent in alignment with their values/priorities).

In addition to ad-hoc contract work, Ruby Central has paid for maintainer conference travel and accommodations to attend conferences. Both as speakers and non-speakers. Though I've not been around for a conf, so I can't speak to what that looks like (who qualifies or how much they get etc).

I think also “being funded” might give off the wrong perception as people might assume (like here) that all the "i"-s are dotted and "t"-s crossed. All proprietary software is "funded" and a lot of it is slow or has other deficiencies. Open source is all about "many eyes." Funding helps some problems, but also makes new ones.

This past year, there was also a full-time security engineer role. This complements the OSS director role (which is also full-time). That position is funded through a grant via another foundation that cares about security, and in the grant, there are specific goals and guidelines for what they hope the position to be. You can read a post about it https://rubycentral.org/news/alpha-omega-supports-ruby-centrals-expansion-of-open-source-leadership-security/. Samuel quit several months ago, and RC has an open job posting for it now. I'm not sure if job posting links are allowed but you can find it on the RC LinkedIn page.

Though from the link I posted, you can see it's much more focused on the service than bundler. Also, more focused on security than speed (not to say the two aren't related).

Sorry for dumping all that. But I think it paints a slightly more nuanced picture of how things were run in the past.

Because it always takes someone to do something. There are not that many people that do :)

It takes someone to succeed for everyone else to follow. uv is impressively fast and most users will experience zero negative side effects.

On the other hand, with npm vs pnpm, where plenty of people do NOT recommend pnpm because of diverging behaviors that break many use cases, despite it being so much faster.

https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-management-tool/

Would you believe that there's already a 'what about uv for ruby' project underway

I'm not sure why it wasn't mentioned in the blog post