5 ms·

I'm not sure whether the author intended "pure-Ruby" to be an advantage or a disadvantage. For me Ruby is a huge no-go and I always try to avoid it if possible

by edem 10y ago

I'm not sure whether the author intended "pure-Ruby" to be an advantage or a disadvantage. For me Ruby is a huge no-go and I always try to avoid it if possible for the simpe reason that no Ruby program works for the first time and whenever I install a gem it is possible that it breaks another. For someone who comes from the distributable binaries world this is simply unbearable.

roryisok 10y ago
Learning ruby at the moment and this is setting off alarm bells. What? gems break each other?
- byroot 10y ago
  That is mostly FUD. It's trendy to hate on Ruby these days. But yes, in Ruby there is a global namespace and open classes, so you can do pretty much whatever you want. But in any language you'll find bad libraries. I mean I can write a go / rust / Java / whatever library that immediately segfault, panic or exit(1) when you invoke it. Does it mean any of those languages are bad?
  - edem 10y ago
    The big difference is that if you download a jar it won't brake your other jars because they work in isolation
- yebyen 10y ago
  If you are learning, then you should learn about rvm, bundler, gemsets, and vendoring gems. There are ways in Ruby to avoid stepping on your own feet with gems, simultaneously whilst avoiding stepping on others feet within in your own team(s) and on the same servers in a traditional Unix-type multi-tenant environment. The central question solved by Bundler is "what version of the gem am I using?" and the core issue addressed by RVM is "what version of Ruby." If you are coming from a tradition of packages for your programming language interpreter that are managed by the OS, and similarly language module packages that come from the OS, and you expect that pattern to just work with Ruby, then yeah, you are quite likely going to have a bad time. Ruby handles these issues internally out of necessity. It does so because for most of us taking this stuff very seriously, we need to be able to run the latest version of the gem (or, any given arbitrary version that our own production release engineering process has settled on) with our chosen OS Distro with the Long-Term Support release. Long term support releases (or, for example, Debian stable releases) use packages that are frozen to a version at a point in time and are likely to be at least a year old. If your gem solves a problem for you but it legitimately hasn't been updated in more than a year, chances are good it's because there's someone else who has made another gem, solving the problem in a better way, and people have already moved on. There is simply no way to address this concern on arbitrarily many OS Distros simultaneously without solving it generally in a way that eschews the OS package manager altogether. When you're committed to solving the problem without the OS package manager's help, bringing it back into the loop is more likely to get in the way than to solve any actual problem. So you find a lot of outdated packages for ruby libraries in OS package managers, when they are even provided at all. I'm not sure if GP had problems with Ruby because of reliance on OS package managers, but if I was a betting man... This is concern #2 from 12 factor methodology of development, Dependency Isolation: https://12factor.net https://12factor.net
  - edem 10y ago
    My problem is that I am not a Ruby dev and when I need to use Ruby stuff they break each other. I expect a language to be able to produce self-contained binaries which run in isolation (and expect this to being the norm). With Ruby I just follow the guides and I always end up in a hour long debug session. If you need your users to know they need bundler or whatever then your language design is flawed.
    - yebyen 10y ago
      Ah, then you do have a problem! I am a Ruby dev, and one of the things I appreciate most about the language is that once I broke down the initial barriers we're talking about now, there was practically nothing stopping me from saying "I am a Ruby dev" It was still years after that before I would dare to say I was a Rails dev, of course... IMHO it is a feature if your language guides people that are at first just passive users to become devs and contribute to your project with issues and pull requests.
      - edem 10y ago
        I have no time/need/want to learn/write Ruby. I have 1000 better things to do. I only use Ruby occasionally and out of necessity.
- steveklabnik 10y ago
  Only use rubygems to "gem install bundler" and "gem install rails" (if you use rails) and use bundler for everything, and you will never have this problem. I second the massive comment below, though I personally prefer ruby-build + chruby over rvm these days.
- edem 10y ago
  It is not FUD. For example I had a working jekyll on my computer when I installed an SASS preprocessor it broke Jekyll.
rajangdavis 10y ago
Can you please provide an example? I have had a few issues here and there with Rails and updating gems, but for the most part, Ruby is a fairly consistent and reliable language. That and the fact that you can use rspec to test your Ruby code, it's kind of hard to find gems without a test suite let alone break immediately...
- edem 10y ago
  For example I had a working jekyll on my computer when I installed an SASS preprocessor it broke Jekyll.

by edem 10y ago

roryisok 10y ago

Learning ruby at the moment and this is setting off alarm bells. What? gems break each other?

byroot 10y ago
That is mostly FUD. It's trendy to hate on Ruby these days. But yes, in Ruby there is a global namespace and open classes, so you can do pretty much whatever you want. But in any language you'll find bad libraries. I mean I can write a go / rust / Java / whatever library that immediately segfault, panic or exit(1) when you invoke it. Does it mean any of those languages are bad?
- edem 10y ago
  The big difference is that if you download a jar it won't brake your other jars because they work in isolation
yebyen 10y ago
If you are learning, then you should learn about rvm, bundler, gemsets, and vendoring gems. There are ways in Ruby to avoid stepping on your own feet with gems, simultaneously whilst avoiding stepping on others feet within in your own team(s) and on the same servers in a traditional Unix-type multi-tenant environment. The central question solved by Bundler is "what version of the gem am I using?" and the core issue addressed by RVM is "what version of Ruby." If you are coming from a tradition of packages for your programming language interpreter that are managed by the OS, and similarly language module packages that come from the OS, and you expect that pattern to just work with Ruby, then yeah, you are quite likely going to have a bad time. Ruby handles these issues internally out of necessity. It does so because for most of us taking this stuff very seriously, we need to be able to run the latest version of the gem (or, any given arbitrary version that our own production release engineering process has settled on) with our chosen OS Distro with the Long-Term Support release. Long term support releases (or, for example, Debian stable releases) use packages that are frozen to a version at a point in time and are likely to be at least a year old. If your gem solves a problem for you but it legitimately hasn't been updated in more than a year, chances are good it's because there's someone else who has made another gem, solving the problem in a better way, and people have already moved on. There is simply no way to address this concern on arbitrarily many OS Distros simultaneously without solving it generally in a way that eschews the OS package manager altogether. When you're committed to solving the problem without the OS package manager's help, bringing it back into the loop is more likely to get in the way than to solve any actual problem. So you find a lot of outdated packages for ruby libraries in OS package managers, when they are even provided at all. I'm not sure if GP had problems with Ruby because of reliance on OS package managers, but if I was a betting man... This is concern #2 from 12 factor methodology of development, Dependency Isolation: https://12factor.net https://12factor.net
- edem 10y ago
  My problem is that I am not a Ruby dev and when I need to use Ruby stuff they break each other. I expect a language to be able to produce self-contained binaries which run in isolation (and expect this to being the norm). With Ruby I just follow the guides and I always end up in a hour long debug session. If you need your users to know they need bundler or whatever then your language design is flawed.
  - yebyen 10y ago
    Ah, then you do have a problem! I am a Ruby dev, and one of the things I appreciate most about the language is that once I broke down the initial barriers we're talking about now, there was practically nothing stopping me from saying "I am a Ruby dev" It was still years after that before I would dare to say I was a Rails dev, of course... IMHO it is a feature if your language guides people that are at first just passive users to become devs and contribute to your project with issues and pull requests.
    - edem 10y ago
      I have no time/need/want to learn/write Ruby. I have 1000 better things to do. I only use Ruby occasionally and out of necessity.
steveklabnik 10y ago
Only use rubygems to "gem install bundler" and "gem install rails" (if you use rails) and use bundler for everything, and you will never have this problem. I second the massive comment below, though I personally prefer ruby-build + chruby over rvm these days.
edem 10y ago
It is not FUD. For example I had a working jekyll on my computer when I installed an SASS preprocessor it broke Jekyll.

rajangdavis 10y ago

Can you please provide an example? I have had a few issues here and there with Rails and updating gems, but for the most part, Ruby is a fairly consistent and reliable language. That and the fact that you can use rspec to test your Ruby code, it's kind of hard to find gems without a test suite let alone break immediately...

edem 10y ago
For example I had a working jekyll on my computer when I installed an SASS preprocessor it broke Jekyll.