I've wanted to learn Ruby for some time and even started to learn a little bit. I then got distracted and for some reason went with Python. I have now however decided that even though my current project is in Python, I will also be learning Ruby and Ruby on Rails.
If somebody were to ask me what version of Python to start with I'd suggest 2.6 because 3 breaks compatibility with all the tutorials they would google. Knowing so little about Ruby, what version should I install on my computer? Is there a major difference between any two versions etc etc?
The version you learn is not that important.
While there will eventually be a shift from the more stable 1.8.x series, 1.9 isn't game breaking in a way where you will be disadvantaged.
Rails recommends version 1.8.7, so if you're going to be learning rails, I'd stick with that. This book is pretty good.
I don't think Ruby has had that many breaking changes - except 1.9 onwards. So any version in the 1.8.x should be fine.. pick the latest stable version.
Rails on the other hand has changed dramatically in Rails 2.
If you're going to be working in Windows, go with the current most stable one-click installer. At time of writing, that would still probably be the 1.8.6-26, although 1.8.6-27 is imminent. 1.8.7 is a small increment and I'm very uncertain about the status of 1.9.1 on the platform.
On OSX or other *nix varieties I'd be prepared to be somewhat more adventurous: the current production Rails release (2.3.2) is supposed to be 1.9.1-compatible (although that may not be the case with all third-party libraries for some time) and learning might be more entertaining with the latest version. It should run a good but faster, too.
Ruby 1.9 makes a few breaking changes, but not like Python 3. Any old Ruby tutorials should work just fine for 1.9. There's nothing like, for example, Python changing print and merging range() with xrange().
It really doesn't make that much difference. The core language hasn't changed a lot — 1.9 is just a lot faster and has gained some new features.
There are some changes that broke some libraries, but those have more to do with the finer implementation details rather than what you learn in basic tutorials, so it shouldn't hurt you. If you want to go with 1.8 for the better library support, that's fine. If you want to go with 1.9 for the better core features, that's fine as well. It doesn't make that much of a difference when you're just starting off.
If you're planning on building stuff that you don't release to the public, that makes use of lots of libraries, 1.8.7 or 1.8.6. If you're writing libraries that will be released to the public, please, please, please make sure they work in Ruby 1.9. Ruby 1.9 is a superior interpreter, but we're stuck with 1.8.x because so many libraries are incompatible with it right now.
http://isitruby19.com/
Learn the latest version. Current latest version is 2.4., but when higher versions are out, go for them immediately. Ruby team pays attention to only release finished work, you don't need to be afraid to install the newest one.
Related
I was wondering if I could use codes based on ruby 2.4 in ruby 3 (as in the programs, methodology, syntax and function names). I would like to slowly migrate to Ruby 3, but I would like to know if everything would be stable.
Do I need to download some package to make it stable? Is Ruby 3 backwards compatible (i heard they are not that much as they are fast innovator's, let's say compared to python which has backwards compatibility for all versions of 3.x but not that much of an innovator)?
Should I go through everything that I have written to make it compatible?
A bit of a tangent, but would it even be necessary for me to migrate to Ruby 3? I would presume that Ruby 2.4 already has enough features and updates for now for me to continue using it, and if I do not go up a version, I can always use Ruby 2.7.
Thanks!
The short answer is pretty No.
You will have as many compatibility issues as many legacy code you have.
Try to reach some resources like https://www.fastruby.io/blog/ruby/rails/versions/compatibility-table.html
But still, If you have well-written tests, they will fail, and deprecation warnings will occur. Those will be some kind of map for you(by fixing issues) to reach a new version.
I used Ruby many years ago and am back hopefully to stay. I recall from several years ago reading that odd-numbered releases of Ruby (eg. 1.9.1, 1.9.3, 1.9.5) are meant for development and that even releases (eg. 1.9.2, 1.9.4) are meant to be production stable. Is this (still) the case or is the latest "stable" as per the Ruby website the way to go?
I've never developed a project as grand as Ruby so I don't know if there are rules for releases that should be followed. Any enlightenment on this topic would be appreciated.
Thank you.
Yes, it is in fact true that odd-numbered releases were unstable in the past. (However, note that "odd-numbered" refers to the minor number, not the tiny number, i.e. 1.1.x, 1.3.x, 1.5.x and 1.7.x were unstable development releases.)
This was changed with Ruby 1.9 for a very simple (and very embarassing) reason: there are tons of Ruby scripts as well as shell scripts (including the scripts that the Ruby maintainers themselves use to automate the development, testing and releasing of Ruby) out there, which simply assume that the major version is a single digit. They would simply break otherwise, mostly because they did things like
if RUBY_VERSION > '1.6.3'
which fails for '1.10.0', because the string '1.10.0' is lexicograhically smaller than the string '1.6.3'.
As a result, it was decided to give up the distinction between odd-numbered and even-numbered releases, and make the next stable release 1.9, because that was easier than convincing everybody that their scripts are broken.
So, the 1.9.0-x series of releases corresponds to 1.9.x under the old numbering scheme (i.e. a series of development releases in preparation of the next release) and the 1.9.(x > 0) series of releases corresponds to 1.10.(x-1), i.e. 1.9.2 is really 1.10.1. (Well, except that 1.9.1 was a botched release, so it is more like a 1.10.0-pre and 1.9.2 is 1.10.0 and 1.9.3 is 1.10.1.)
Also, Ruby 2.0 is intended to be fully backwards-compatible, which means that it's really 1.12 ... does that clear up any confusion? :-)
So, in summary: Yes, it used to be true (but in a different way than you thought), but it is no longer true, and hasn't been true since the 1.7 series which ended with the release of Ruby 1.8.0 in August of 2003, over eight years ago.
Nope, that's not the case. I don't think it was ever the case with ruby. 1.8.6 and 1.8.7 were considered stable, as are 1.9.2 and 1.9.3.
You might be thinking of Linux kernels, that's how they do it there.
well guess that many of you have great expertise on Linux. I currently have some issues with creating a linux-live-medium.
i have a box with OpenSuse-Linux Version 11.3 with all nice things. Several languages run very well: Perl, Python, PHP! All is very well! BTW - i am very glad that Perl runs very nice.
But I am not able to install Ruby 1.9. Everytime i want to do that i end up with Ruby 1.8.7. I want to testrun some ruby-code. Therefore i need Ruby with the following gems
mechanize
nokogiri
utf8_utils
I heard of a Linux-Live-medium that is able to run with all the wanted things including Ruby 1.9.
Therefore the Live-medium is installed on a USB-Stick with R/W partitions. Is this possible.
I am not a linux-expert - but with all the expertise here i think it is possible to create such a USB-Stick. (...with Ruby 1.9 and all with all that extensions)
I love to hear from you!
best regards
zero
Debian/Ubuntu includes both Ruby 1.8.x and 1.9.x - and essentially duplicates most packages in 2 flavors: for 1.8 and 1.9. That might be enough for your purposes - although YMMV, of course.
Yet another solution is RVM that karudzo already mentioned.
Yet another solution is virtualization: simplest form of it would be just chrooting. Most modern Linux systems have an ability to install itself based from some root directory (SuSE has install into given directory functionality, Debian/Ubuntu have debootstrap - and then just running chroot /path/to/that/directory - you'd end up in essentially another system installed cleanly in separate directory.
This will actually be a better solution for you- use RVM:
https://rvm.io/
Then you can easily switch back and forth from 1.8 to 1.9 as desired and make 1.9.2 your default. Just read their docs carefully, it really makes gem management a lot easier.
I know there is ongoing work for in this regards but what is the exact status of JRUby 1.3 compatibility with Ruby 1.9.1 ? I am slightly confused if I can dwnload jruby 1.3 and start working with my ruby 1.9 installation.
The JRuby homepage says :
* Ruby 1.8.6 compatible now
* Ruby 1.9 compatible soon
Wikipedia says the following:
Release history
This table present only releases that present significant steps in JRuby history, aside from versions that mainly fixed bugs and improved performance.
Release Release Date Highlights
0.9 2006-08-01 Rails support[11]
1.1 2008-03-28 Performs better than Ruby MRI 1.8.7[6]
AOT mode and JIT mode[21]
1.1.4 2008-08-28 Refactored Java integration layer
Beginning of Ruby 1.9 support
FFI subsystem for calling C libraries[22]
1.2.0 2009-03-16 Ruby 1.9 support almost complete (including JIT compiler)
Preliminary Android support
A detailed overview of what is done and what is missing can be found on their wiki. From that page:
These are entire areas that need to be worked on.
Encoding::Converter
Yielder/Generator
key Marshal changes
cli options
some RubyBignum changes
possible other changes in Numerics
changes in Dir/IO/File (some obvious things are done, like enumeratorize)
some changes in Math
encoding information in exception messages (now passed via java String)
BigDecimal changes ?
In general, though, I think you'll be fine if you use JRuby for Ruby 1.9 code. Any errors that you may have will be few and far between, and easily fixable (for the most part). I recommend you try your code with the latest JRuby, and if it doesn't work, then you know not to use it yet.
Update to 1.6.4 and you'll get JRuby 1.9 with the --1.9 flag, or with the JRUBY_OPTS environment variable set to --1.9.
Here's an update from the 11/2/2009 release notes for Jruby 1.40:
We have also gotten more serious about
out 1.9 support (–1.9). The bigger
applications mostly just work at this
point, but we still have a ways to go
on 1.9 support. Please try your 1.9
code in JRuby and help us firm things
up.
Having struggled with Rails when it almost worked under JRuby, I'd advise sticking with 1.8x for now if you're doing production work. The JRuby guys are great, and I'm sure they'll nail 1.9, but in the meantime, living on the edge is painful when you're trying to get things done.
There are multiple Ruby implementations in the works right now. Which are you looking forward to and why? Do you actively use a non-MRI implementation in production?
Some of the options include:
Ruby MRI (original 1.8 branch)
YARV (official 1.9)
JRuby
Rubinius
IronRuby - Ironruby.net
MagLev (Thanks Julian) Github link
MacRuby (Thanks Damien Pollet)
Maglev. It will have the speed benefit of all the optimization that has gone into a major Smalltalk VM over many, many year. Plus it will automatically persist all your data pretty much automatically so there is no more need to monkey around with Object-Relational mapping layers and so on.
Ruby 1.9 (YARV) gives us a good idea as to where ruby is headed, but I wouldn't recommend using it for production use. While it's certainly much faster than 1.8, even some parts of the syntax keep changing, so I don't think you could call it stable. It does have some interesting new features and syntax which will surely find their way into all the other implementations over time.
JRuby and IronRuby are useful in that they give ruby access to a whole range of new libraries and environments where ruby couldn't be used otherwise. I've not found much use for them myself yet, but think it's great that they exist. They may allow ruby to infiltrate corporate environments where it wouldn't otherwise be permitted. That can only be a good thing.
Rubinius and Maglev are probably the most interesting projects, but also those where their benefit to the community is likely to be furthest into the future. Rubinius may well develop into a cutting edge 'pure' VM for the ruby language, allowing ruby code to run much faster than it can now. Maglev too seems extremely promising, backed as it is by 20+ years of VM experience. It will also provide features over and beyond a standard VM, but of course these will come at the cost of code portability.
Overall though, what I'm most excited about is the competition between these implementations. Having competing projects all working to make ruby better can only make the ruby ecosystem stronger. From what I've seen too, while the competition exists it is friendly; each project giving and taking ideas from each other. The work done by the JRuby and Rubinius teams in creating a ruby spec is probably the most important outcome so far, as it will help ensure that all implementations remain compatible.
jRuby is stable and reliable today. Maglev is very promising.
No one mentioned MacRuby yet? I guess it's a bit Mac-specific now, but it could probably be made to compile to the GNU or Étoilé objective-c runtimes too.
Also, I'm waiting for Maglev :)
What about Enterprise Ruby? This has been out there for a while.
https://www.phusionpassenger.com/enterprise