3 ms·

I've been using python for two decades and ruby exactly one decade ago for a couple years. Your comment on packaging is interesting. My perspective is that pa

I've been using python for two decades and ruby exactly one decade ago for a couple years. Your comment on packaging is interesting. My perspective is that packaging on ruby was in nearly the same state ten years ago as python is now. My team switched ruby package managers several times during the ruby work and none of them ever worked reliably and was a regular root cause of fragility in our builds. I hope that ruby packaging has settled in that time while python has the same kind of cultural noise that afflicted ruby during that period. Popularity has downsides. Political packaging wars is one of them. I'm old school enough that I stick with tried and true pip, venv, and .env and its ilk. There was a long battle in downstream packaging for a while that I just didn't want to be involved in having seen the same thing in ruby. FWIW, if I were you I'd look at crystal, elixir, or nim. I was very productive in ruby but the near constant battle of wrestling with DSL's that are not concomitant with their parent is, IMHO, to be avoided. I've seen more than one team fall prey to that trap. Caveat emptor - pick your DSL's carefully.

kawsper 4y ago
What do you mean by switching packaging managers? Ruby uses Rubygems and Bundler to manage packages. Are you referring to Ruby version managers that manages different versions of Ruby (rbenv, rvm, asdf, etc.)?
- ByteJockey 4y ago
  They mention doing this a decade ago. They were probably using utilities to manage downloads from the ruby application archive (which would have still been around at the time) and automate running `setup.rb`
  - davidthewatson 4y ago
    Yes, all of the above. Sorry for the unclear language. At the time, I recall it being very distracting when the team was focused on shipping well-tested code. We had a world class devops guy, but we all ran into these build issues frequently enough that it was a regular complaint at retrospectives no matter what tooling we were using at the time or who was using it. It was not long after this that I read Daniel Greenfeld's book on Django that introduced the notion of "vanilla django" and that resonated with me, precisely because our rails tooling was decidedly not vanilla. My take now is that rails can have the same problems with regard to being "off the rails" WRT the aforementioned DSL's and such. I don't think the root cause is ruby as much as there are pockets of rails that are far from what DHH describes.

kawsper 4y ago

What do you mean by switching packaging managers? Ruby uses Rubygems and Bundler to manage packages. Are you referring to Ruby version managers that manages different versions of Ruby (rbenv, rvm, asdf, etc.)?

ByteJockey 4y ago
They mention doing this a decade ago. They were probably using utilities to manage downloads from the ruby application archive (which would have still been around at the time) and automate running `setup.rb`
- davidthewatson 4y ago
  Yes, all of the above. Sorry for the unclear language. At the time, I recall it being very distracting when the team was focused on shipping well-tested code. We had a world class devops guy, but we all ran into these build issues frequently enough that it was a regular complaint at retrospectives no matter what tooling we were using at the time or who was using it. It was not long after this that I read Daniel Greenfeld's book on Django that introduced the notion of "vanilla django" and that resonated with me, precisely because our rails tooling was decidedly not vanilla. My take now is that rails can have the same problems with regard to being "off the rails" WRT the aforementioned DSL's and such. I don't think the root cause is ruby as much as there are pockets of rails that are far from what DHH describes.