←back to thread

333 points steveklabnik | 1 comments | | HN request time: 0.259s | source
Show context
ufmace ◴[] No.45036735[source]
On the one hand, it's nice to see Ruby and the Ruby tooling system getting some love.

On the other, I'm not sure if this is really needed. Most of this stuff already works fine in Ruby with Bundler. Did you know that Bundler already has a really nice syntax for inline requirements for single-file scripts?[0] Seems like a lot of people forgot. Installing Ruby hasn't generally been much of a hassle either AFAIK. Bundler also doesn't seem to have the Python venv problem - it works fine for keeping a bunch of gem versions around in the same Ruby install and only activating the specified ones. I think Gemfile and Gemfile.lock is what Python always wished they had. I guess more speed never hurt, but it never felt like bundler was painfully slow for me, even on huge codebases. So is there really a big win here?

Though I guess plenty of Python gurus probably feel the same way about the uv craze when their existing tooling works well enough for them.

[0] https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

replies(4): >>45037254 #>>45037425 #>>45038161 #>>45039248 #
1. pxc ◴[] No.45039248[source]
As someone who uses Nix and direnv to manage development environments, the additional speed will be nice for me. I don't need rv to supply a Ruby for me at all, but just a really fast Bundler would be nice.

My environment reasserts that the correct things are installed every time I change into the directory. A no-op Bundle install takes a couple hundred milliseconds, which is not great for something you want to run constantly and automatically. Getting that down to tens of milliseconds will be really nice for me!