6 ms·

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

by hit8run 12y ago

hackerboos 12y ago
That's what happens when you maintain two versions, one of which has fundamental breaking changes. When the Ruby team makes changes the attitude is generally 'deal with it'. Sure they still do point releases on older versions but only for security issues AFAIK. Python moves forward it just does a poor job of dragging everyone with it.
- dagw 12y ago
  When the Ruby team makes changes the attitude is generally 'deal with it' However they complement this attitude by being a lot better at working with big 3rd party library developers and making sure they are on board. To the best of knowledge there has never been a Ruby release that was incompatible with RoR for any period of time. Compare to Python that jumped to python 3 without either numpy or Django on board.
  - yxhuvud 12y ago
    Well, on the other hand I definitely remember a point release of 1.8.7 that broke Rails :)
    - wycats 12y ago
      Momentarily, and Matz appeared to feel so bad about it that they have been far more aggressive about tiny-version changes ever since.
- reledi 12y ago
  Sounds about right. Coming from a Python background to Ruby, I think there's more to it though. For example, Ruby version managers such as rvm and rbenv help a lot with keeping the community moving forward. Python has virtualenv but it always felt awkward to me compared to what Ruby has.
  - berdario 12y ago
    You have a plethora of similar tools in the python world as well: - Pythonz - Conda - Pew (disclaimer: I'm the author) - Virtualenvwrapper - Pyenv Etc. If you argue that people might not move to the latest and greatest as soon as possible due to the fact that people don't build their own interpreter, I can definitely agree with it: python users seem to truly prefer the python version that already comes pre-installed with their linux distribution
    - reledi 12y ago
      > python users seem to truly prefer the python version that already comes pre-installed with their linux distribution Definitely. It's not that Python doesn't have the tools to switch between versions, but it's not as prevalent as is in the Ruby community. Most Python users will start their program with shebangs like #!/usr/bin/env python or if they want Python 3+ #!/usr/bin/env python3 while not necessarily using tools like virtualenv and virtualenvwrapper. I feel like shebangs are not as commonly used in Ruby, instead you use tools and your Gemfile to specify Ruby version.
      - alxndr 12y ago
        Unfortunately that's lead me to need to specify my intended ruby version in several places on a ruby project (.ruby-version, Gemfile, CI config file...)
      - weaksauce 12y ago
        Well, Ruby version and the versions of all your dependencies and the versions of gems for different environments.
    - kennyledet 12y ago
      pythonz looks great, thanks
  - jrochkind1 12y ago
    Interesting, I haven't worked in python, but I was always jealous of python having a single 'official' solution in virtualenv, instead of ruby, where it's confusing for newcomers to figure out which one they should be using (rvm? rbenv? chruby?), and each solution has it's annoyances and problems. I always thought it would be better if the community unified it's efforts behind one solution and made sure it was bug-free, and where the language's binaries or behaviors might actually be changed when needed to support that solution. Maybe it's just the grass is always greener.
berdario 12y ago
Sure, but be aware that if Ruby ever decides to fix the situation with its Strings types/encoding, you'll get the exact same "disaster". At least in the python world this change is now mostly in the past.
- matthewmacleod 12y ago
  What situation is that, out of interest? As of Ruby 1.9, there's a pretty sensible solution to this in the language, and I haven't had any encoding problems in some time. I appreciate I might have missed something though!
  - berdario 12y ago
    (I'll try to keep this short, since I feel this is quite offtopic, if we want to discuss this further I suppose we could find a better venue... maybe even email?) I assume that with "Ruby 1.9 solution", you refer to the fact that Ruby source code is by default evaluated as UTF-8, right? That's definitely a good thing, but with Python3 that wasn't the only change brought into the language. I said "if Ruby ever decides to fix", because the need for a change is not obvious and not universally accepted: it's basically the same issue as automatic type coercion (aka weak/strong typing) and early (or late) raise/throw/handling of exception. Basically: In Python2 and Ruby you have one or two String types (runtime types, in this discussion I only care about them), with the Ruby Strings tagged with the encoding internally used. In python the types are just "anything goes" (binary strings, the old Python2 string) and unicode (the actual internal encoding is an implementation detail). The problem (if you agree that it is one) is that you can easily mix-and-match them, and everything will work fine only as long as the operation makes sense. When it won't anymore you'll get an exception. This is a problem when you don't completely control the type/encoding of your input (e.g. if you have an HTTP request and your string depends on the type/charset specified in the Content-Type). A dumb example of what could happen: a = "Ё".force_encoding "ISO-8859-5" a2 = "®".force_encoding "ISO-8859-1" # a + a2 will fail with Encoding::CompatibilityError A similar thing can happen in Python2. While Python3 will reject the same operation as soon as the types get in contact with each other (still at runtime, but it'll be like doing `1+"1"` in Python or Ruby: you'll spot it right away). I wrote a quite lengthy blog post about this change in Python3, but I haven't translated it in English yet, if there's some interest I could try to do it a bit sooner. Anyhow, I don't want to create a flame or anything like that. I just wanted to explain why the Python3 choice has been made, and why a destructive change might have had its merit. While I prefer the Python3's approach, and I'm definitely not a Ruby developer, I still appreciate these updates to Ruby: for example I actually touched first hand the internal encoding-handling code of Ruby (Rubinius) some time ago with a friend of mine: http://git.io/7kM4Gw http://git.io/7kM4Gw and I can benefit from the new GC code in new rubies, which makes metasploit 4 times faster to load.

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

by hit8run 12y ago

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

hackerboos 12y ago

That's what happens when you maintain two versions, one of which has fundamental breaking changes. When the Ruby team makes changes the attitude is generally 'deal with it'. Sure they still do point releases on older versions but only for security issues AFAIK. Python moves forward it just does a poor job of dragging everyone with it.

dagw 12y ago
When the Ruby team makes changes the attitude is generally 'deal with it' However they complement this attitude by being a lot better at working with big 3rd party library developers and making sure they are on board. To the best of knowledge there has never been a Ruby release that was incompatible with RoR for any period of time. Compare to Python that jumped to python 3 without either numpy or Django on board.
- yxhuvud 12y ago
  Well, on the other hand I definitely remember a point release of 1.8.7 that broke Rails :)
  - wycats 12y ago
    Momentarily, and Matz appeared to feel so bad about it that they have been far more aggressive about tiny-version changes ever since.
reledi 12y ago
Sounds about right. Coming from a Python background to Ruby, I think there's more to it though. For example, Ruby version managers such as rvm and rbenv help a lot with keeping the community moving forward. Python has virtualenv but it always felt awkward to me compared to what Ruby has.
- berdario 12y ago
  You have a plethora of similar tools in the python world as well: - Pythonz - Conda - Pew (disclaimer: I'm the author) - Virtualenvwrapper - Pyenv Etc. If you argue that people might not move to the latest and greatest as soon as possible due to the fact that people don't build their own interpreter, I can definitely agree with it: python users seem to truly prefer the python version that already comes pre-installed with their linux distribution
  - reledi 12y ago
    > python users seem to truly prefer the python version that already comes pre-installed with their linux distribution Definitely. It's not that Python doesn't have the tools to switch between versions, but it's not as prevalent as is in the Ruby community. Most Python users will start their program with shebangs like #!/usr/bin/env python or if they want Python 3+ #!/usr/bin/env python3 while not necessarily using tools like virtualenv and virtualenvwrapper. I feel like shebangs are not as commonly used in Ruby, instead you use tools and your Gemfile to specify Ruby version.
    - alxndr 12y ago
      Unfortunately that's lead me to need to specify my intended ruby version in several places on a ruby project (.ruby-version, Gemfile, CI config file...)
    - weaksauce 12y ago
      Well, Ruby version and the versions of all your dependencies and the versions of gems for different environments.
  - kennyledet 12y ago
    pythonz looks great, thanks
- jrochkind1 12y ago
  Interesting, I haven't worked in python, but I was always jealous of python having a single 'official' solution in virtualenv, instead of ruby, where it's confusing for newcomers to figure out which one they should be using (rvm? rbenv? chruby?), and each solution has it's annoyances and problems. I always thought it would be better if the community unified it's efforts behind one solution and made sure it was bug-free, and where the language's binaries or behaviors might actually be changed when needed to support that solution. Maybe it's just the grass is always greener.

berdario 12y ago

Sure, but be aware that if Ruby ever decides to fix the situation with its Strings types/encoding, you'll get the exact same "disaster". At least in the python world this change is now mostly in the past.

matthewmacleod 12y ago
What situation is that, out of interest? As of Ruby 1.9, there's a pretty sensible solution to this in the language, and I haven't had any encoding problems in some time. I appreciate I might have missed something though!
- berdario 12y ago
  (I'll try to keep this short, since I feel this is quite offtopic, if we want to discuss this further I suppose we could find a better venue... maybe even email?) I assume that with "Ruby 1.9 solution", you refer to the fact that Ruby source code is by default evaluated as UTF-8, right? That's definitely a good thing, but with Python3 that wasn't the only change brought into the language. I said "if Ruby ever decides to fix", because the need for a change is not obvious and not universally accepted: it's basically the same issue as automatic type coercion (aka weak/strong typing) and early (or late) raise/throw/handling of exception. Basically: In Python2 and Ruby you have one or two String types (runtime types, in this discussion I only care about them), with the Ruby Strings tagged with the encoding internally used. In python the types are just "anything goes" (binary strings, the old Python2 string) and unicode (the actual internal encoding is an implementation detail). The problem (if you agree that it is one) is that you can easily mix-and-match them, and everything will work fine only as long as the operation makes sense. When it won't anymore you'll get an exception. This is a problem when you don't completely control the type/encoding of your input (e.g. if you have an HTTP request and your string depends on the type/charset specified in the Content-Type). A dumb example of what could happen: a = "Ё".force_encoding "ISO-8859-5" a2 = "®".force_encoding "ISO-8859-1" # a + a2 will fail with Encoding::CompatibilityError A similar thing can happen in Python2. While Python3 will reject the same operation as soon as the types get in contact with each other (still at runtime, but it'll be like doing `1+"1"` in Python or Ruby: you'll spot it right away). I wrote a quite lengthy blog post about this change in Python3, but I haven't translated it in English yet, if there's some interest I could try to do it a bit sooner. Anyhow, I don't want to create a flame or anything like that. I just wanted to explain why the Python3 choice has been made, and why a destructive change might have had its merit. While I prefer the Python3's approach, and I'm definitely not a Ruby developer, I still appreciate these updates to Ruby: for example I actually touched first hand the internal encoding-handling code of Ruby (Rubinius) some time ago with a friend of mine: http://git.io/7kM4Gw http://git.io/7kM4Gw and I can benefit from the new GC code in new rubies, which makes metasploit 4 times faster to load.