Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can Bundler be as fast as uv?

tenderlovemaking.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: Can Bundler be as fast as uv?

#71

Post by shevy-java »

AlphaSite wrote: post #23
dbalatero wrote: post #8

I appreciate that Aaron is focusing on the practical algorithm/design improvements that could be made to Bundler, vs. prematurely going all in on "rewrite in Rust".

Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.

I manage all my programs via ruby in a manner similar to GoboLinux, e. g. versioned AppDirs. So I don't need uv or anything else for this - not that I have anything against uv, it is just not something I need myself. But I agree with you in that there are multiple objectives or goals to be had here; you mention one, Aaron mentioned speed. I think there are many more (I mentioned documentation before too; people in ruby seem to think documentation is not important, or at the least really many think in that way - look at the documentation of rack, it is virtually not existing. I am not going to sift through low quality ruby code for hours to try to figure out what madness drove this or that author to write some horrible-to-read junk of code. A project without good documentation is worthless. Why do ruby developers not learn this lesson?).

I think all of ruby, including the ecosystem as well as how ruby is governed, needs to be considered. In particular with ruby constantly declining and losing user share. That is not good. That should change.

Re: Can Bundler be as fast as uv?

#72

Post by shevy-java »

stouset wrote: post #32
AlphaSite wrote: post #23

Earlier quoted context omitted.

Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.

Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.

Well. GoboLinux solved that already. Back in 2005.

I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)

Re: Can Bundler be as fast as uv?

#73

Post by 8n4vidtmkvmk »

shevy-java wrote: post #70
dbalatero wrote: post #8

I appreciate that Aaron is focusing on the practical algorithm/design improvements that could be made to Bundler, vs. prematurely going all in on "rewrite in Rust".

Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here. I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users. This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the s…

I don't know a lot about Ruby, but I'd wager what its missing is a hero app or framework. Ruby on Rails got folks interested for awhile, but I guess other frameworks won out. What left does it have? What domains does it excel at?

Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety.

That probably covers like 99% of things, at least from my world view. There are arguably other better languages but it doesn't much matter if the community all flocks to the well established ones.

Re: Can Bundler be as fast as uv?

#74

Post by johnisgood »

shevy-java wrote: post #72
stouset wrote: post #32

Earlier quoted context omitted.

Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.

Well. GoboLinux solved that already. Back in 2005. I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)

Or GNU Stow.

Re: Can Bundler be as fast as uv?

#75

Post by ayuhito »

maccard wrote: post #30
byroot wrote: post #22

Earlier quoted context omitted.

GHA with the `setup-ruby` action will cache gems. Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.

> GHA with the `setup-ruby` action will cache gems. Caching is a great word - it only means what we want it to mean. My experience with GHA default caches is that it’s absolutely dog slow. > Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependen…

> My experience with GHA default caches is that it’s absolutely dog slow.

For reference, oven-sh/setup-bun opted to install dependencies from scratch over using GHA caching since the latter was somehow slower.

https://github.com/oven-sh/setup-bun/issues/14#issuecomment-...

Re: Can Bundler be as fast as uv?

#76

Post by solatic »

nightpool wrote: post #3

Really interesting post, but this part from the beginning stuck out to me: Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about…

For a "YAML" lockfile, you could probably write a much simpler and much more performant parser that throws out much of what makes YAML complicated, in particular, anchors, data type tags, all the ways of doing multi-line strings, all the weird unexpected type conversions (like yes/no converting to a boolean)... If the lockfile is never meant to be edited by human hands, only reviewed by human eyes, you can build a much simpler parser for something like:

  version: "1"
  dependencies:
    foo:
      version: "1.0"
      lock: "sha-blabla"

Re: Can Bundler be as fast as uv?

#77

Post by Kwpolska »

8n4vidtmkvmk wrote: post #73
shevy-java wrote: post #70

Earlier quoted context omitted.

Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here. I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users. This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the s…

I don't know a lot about Ruby, but I'd wager what its missing is a hero app or framework. Ruby on Rails got folks interested for awhile, but I guess other frameworks won out. What left does it have? What domains does it excel at? Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety. That probably covers like 99% of things, at least from my world view. There are arguably…

There is no single established framework/language for backend Web development. There are many options, all valid, differing in popularity based on their qualities (or sometimes just hype).

Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.

Re: Can Bundler be as fast as uv?

#78

Post by riffraff »

jjgreen wrote: post #19
IshKebab wrote: post #17

Earlier quoted context omitted.

> Man, it's easy to be fast when you're wrong. There's never going to be a Python 4 so I don't think they are wrong. Even if lighting strikes thrice there's no way they could migrate people to Python 4 before uv could be updated to "fix" that. > Ambiguity detection is important. I'm not sure what you mean here. Pip doesn't detect any ambiguities. In fact Pip's behaviour is a gaping security hole that they've refused…

There's never going to be a Python 4 There will, but called Pyku ...

Took me way too long to get this joke, but when did I giggled, thank you.

Re: Can Bundler be as fast as uv?

#79

Post by jacobtomlinson »

dirtbag__dad wrote: post #56
NSPG911 wrote: post #53

Earlier quoted context omitted.

mise is pretty nice, though I don't use it for python, Python is handled by uv with poethepoet as the task runner.

Can you help me understand what the value or use case of poethepoet is?

It allows you to define common tasks such as linting, running tests, building docs, etc under an alias.

So you can run

uv run poe docs

Instead of

uv run sphinx-build -W -b dirhtml docs/source docs/build

Many languages have a task runners baked into their package manager, but many others don’t. In Ruby it’s roughly the equivalent of Rake.

Re: Can Bundler be as fast as uv?

#80

Post by pantulis »

Kwpolska wrote: post #77
8n4vidtmkvmk wrote: post #73

Earlier quoted context omitted.

I don't know a lot about Ruby, but I'd wager what its missing is a hero app or framework. Ruby on Rails got folks interested for awhile, but I guess other frameworks won out. What left does it have? What domains does it excel at? Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety. That probably covers like 99% of things, at least from my world view. There are arguably…

There is no single established framework/language for backend Web development. There are many options, all valid, differing in popularity based on their qualities (or sometimes just hype). Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.

> Ruby used to be cool around 2010, but it lost to better options.

I'd argue that it lost the cool kidz mindshare but not to better options. People jumped to Node.js because of async but in the end the relevant industry change was the switch to SPA based architectures in the web space. Rails never embraced that approach and hence lost the popularity.

Jump 15 years ahead, and now the Enterprise world is built with React and Angular apps, not with JSPs or Spring MVC apps. Can Rails do a comeback? Who knows, but it's still a bona fide web development stack with terrific productivity gains for those who want to optimize that metric.

Post reply on HN