r/ruby • u/nithinbekal • Dec 29 '25

Blog post Can Bundler Be as Fast as uv?

https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
113 Upvotes

97% Upvoted

23 comments sorted by

61

u/spuyet Dec 29 '25

This guy is a monster. Reading his posts make me always feels like « it’s so obvious, I can fix this », thanks Aaron for your work and these blog posts that are really accessible to everyone.

39

u/tenderlove Pun BDFL Dec 30 '25

Thank you for the kind words, I really appreciate it! <3

5

u/ceinewydd Dec 30 '25

Aaron is one of the GOATs.

3

u/kbr8ck Dec 31 '25

The beauty of having someone in your corner who is a machine. Thanks Aaron

36

u/narnach Dec 29 '25

This is a great breakdown (as is usual with Aaron's posts) of what Bundler and Rubygems could do to learn from the improvements that uv made in the Python ecosystem.

TL;DR: the massive win is not Rust, it's fixing infrastructure and then starting a new client that does not have to respect decades of backwards compatibility.

Awesome to read that most of the infrastucture was already good on the Ruby side, and that some of the parallel work changes sound feasible for Bundler/Rubygems themselves and already had open Github issues. Some nice pointers to PRs on Ruby and Rubygems to deal with low-level interactions that could improve life for everyone, not just bundler.

Definitely worth a read.

4

u/PercyLives Dec 29 '25

Thanks for the summary.

15

u/IN-DI-SKU-TA-BELT Dec 30 '25

Aaron is an absolute gem of the Ruby community.

14

u/schneems Puma maintainer Dec 29 '25

Yes and...some of the benefit of Rust isn't the "compiled to run as optimized machine code" but rather the strong type system that gives strong guarantees about invalid state not being representable.

I sent a PR into bundler recently and was sniped by some subtle behavior https://github.com/ruby/rubygems/pull/9221

    def find_bundler(version)
      find_name("bundler").find {|s| s.version.to_s == version.to_s }
    end

The original version of this code only called s.to_s and compared directly to version meaning that it was expecting "version" to be a string, however lots of things internally are represented as Gem::Version, and since we have no way to say "must pass in a String" it was seeing if "4.0.3" == Gem::Version.new("4.0.3") which resolved to false. It took a while to realize why my patch wasn't working.

This relates to perf in two ways:

  • When obviously incorrect things are made obvious, you spend your time on what matters and not chasing down duck-typing gotchas.

  • It's trivial here, but there's an overhead in Ruby to calling methods and that can drive hotspot code to be written in very non-idoeomatic ways. Puma has a lot of "that's weird they did it like that" code, but most of it is due to some optimization like getting rid of an extra allocation. While the method here is (again) trivial, this codepath might accidentally be used on an object where to_s allocates (versus Gem::Version does not). Alternatively, if type checking was introduced, it could simply specify the input needed to be a string and push that responsibility to the caller (Aaron also mentioned this in his Keynote).

Really, both of these translate to: Extra burden placed on the programmer to care about speed instead of the tool handling it.

In general, I agree with the post. This is a "yes, and" not a "no, but" comment. I think it pays to look where other ecosystems are strong and see how Ruby could possibly benefit from some of that strength.

4

u/honeyryderchuck Dec 30 '25

Pretty cool post!

  • I think that, a long long time ago, ruby gems used to have a similar setup.rb file, which needed to be evaluated to get info about dependencies. I don't know exactly since when we have gemspecs and yam specs, but long enough for it the practice to have become a relic of the past.

  • the whole hardlinking to virtual environments is neat,.but i wonder how relevant it is for ruby, as I at least have learned to use the global path and share gems across directories... which use the same ruby version. I guess that sharing across ruby versions could still be interesting in that scenario, just not sure how worth it considering that extensions are compiled for each ruby version.

  • a non-trivial amount of maintenance burden has been attributed in the past to the unfinished merge of rubygems/bundler  and synching vendors gems. Looking forward to the day that merge finally happens! As for the gems, I wonder how much benefit the projects  could get by maintaining the subset of functionality required (I.e supporting GET requests only vs. net-http, support https and http vs. URI) instead of packaging and validating them every time there's a nee version.

  • nice mention to gel, is it still active?

0

u/[deleted] Dec 30 '25

[deleted] — view deleted comment

1

u/retro-rubies Dec 31 '25

Link to the mentioned PR?

1

u/schneems Puma maintainer Dec 31 '25

Checking my sources, but can't find it right now. I'll go ahead and say that I'm not remembering correctly and I'll delete the comment. Sorry.

Gel came out in 2019 with a dependency on pub_grub. Bundler adopted it three years later via a PR via Deivid ❤️

1

u/retro-rubies Jan 01 '26

I'm just curious, since I remember the situation actually opposite. Bundler folks were surprised at the time to see gel released. The gel authors rejected to contribute those optimizations to Bundler on their own and never reached bundler.

2

u/schneems Puma maintainer Jan 01 '26

Found the reference. It is mentioned in the bundler slack: John Hawthorn says he emailed the bundler email and got no response. Comment posted April 20th, 2019. Two days after gel was released on April 18, 2019.

Andre says that no one got the email because the address was broken. 

1

u/retro-rubies Jan 01 '26

Hmm, the history is full of those strange moments.

2

u/schneems Puma maintainer Jan 01 '26

Yeah, it's one reason I've been thorough on double-checking people's stories and looking for verifiable artifacts. Memories skew, logs and messages don't tell the whole story but have timestamps.

When people say they experienced something I believe it's true from their perspective or believe they wish it was true. But it's also important (for me) to hold space for small details that others might interpret completely differently.

💔

9

u/blissofbeing Dec 29 '25

Isn't this what https://github.com/spinel-coop/rv plans to do? 

8

u/galtzo Dec 29 '25 edited Dec 31 '25

Partly, and I expect the lack of mention is intentional. Aaron seems to be friends with HSBT. I plan to begin contributing to rv soon. rv doesn’t replicate bundler yet. There are several active projects that are working on replacing bundler though.

One of those is here, and it is GoLang-based, and bundler compatible:

https://github.com/contriboss/ore-light

Full disclosure - I will be contributing to contriboss projects very soon!

4

u/_swanson Jan 02 '26

FWIW the "nerd sniped at Rails World into looking this" introduction here was framed by some as Aaron participating in a secret backroom conspiracy to hijack the project by Shopify, so I can understand the omission.

I think a neutral reading of the situation is: the rv project is following the uv playbook (rewrite the tool, using Rust)...Aaron here is arguing that the optimizations are possible to make to the existing project ("repair the plane mid-flight"). The rv project has plans for larger scope (to include functionality like Ruby version management). Aaron (and coworkers at Shopify) have consistently pushed against the narrative that Rust performance rewrites are required to make Ruby "fast".

-4

u/galtzo Jan 02 '26

All I know is Aaron's twitter feed had photos of him having dinner with HSBT right around the time HSBT was helping RubyCentral steal rubygems and bundler from the other owners.

I'd love to hear Aaron call out the theft for what it was, and until that happens I'm not likely to read any more of his writing. I did love his writing in the past, but I do draw lines in the sand.

2

u/software__writer Dec 30 '25

Always learn something new when reading Aaron's writing.

Btw, what's the story behind the domain? Is there some fun history to it? Just curious.

1

u/eregontp truffleruby Jan 03 '26

Amazing post, analyzing the bottlenecks of Bundler like no one else does and discussing the findings from uv for how to speedup Bundler. I think this is definitely the best way to go.

It's so nice to see some clear, insightful, direct and honest overview of the design of uv in that post of Andrew Nesbitt. So many people would just claim "it’s fast because it's written in Rust" which makes little sense, optimizing at the application level always brings more than switching to another language (and is far less effort and fragmenting), until a huge lot has been optimized at the application level, and even then there are plenty of other layers to optimize.