←back to thread

333 points steveklabnik | 1 comments | | HN request time: 0.24s | 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 #
byroot ◴[] No.45037254[source]
Same. Python’s virtual env always seemed to me like a weirdly complicated workaround for the limitations of the Python package managers.

Ruby/Bundler doesn’t have any of these problems, and nothing on their roadmap really excite me.

Except maybe the binary Ruby distribution, but it’s a once or twice a year thing, so not exactly a major pain point.

replies(2): >>45037691 #>>45038132 #
1. lathiat ◴[] No.45038132[source]
Right. Everyone seemed to be struggling with problems in python now that we’re already solved in Ruby 2007-2010.