Ruby 2.0.0 Released
An anonymous reader writes "Today version 2.0.0 of Ruby has been released. This is a stable release, and the Ruby team has done their best to make it compatible with 1.9, making it easier to migrate than it was to switch from 1.8 to 1.9. New core language features include: 'Keyword arguments, which give flexibility to API design; Module#prepend, which is a new way to extend a class; A literal %i, which creates an array of symbols easily; __dir__, which returns the dirname of the file currently being executed; and UTF-8 default encoding, which make many magic comments omissible.' There are also new built-in libraries for lazy stream and for an asynchronous exception handling API. The release includes a number of performance improvements and debug support for DTrace."
where can I get my ruby 2.0.0 slippers?
Use RVM:
rvm get head && rvm install 2.0.0
Should have been released on Tuesday. Ruby Twosday. :D
Your code indentation is wrong.
Your message is basically a trap. In order to answer, one has to accept the implied assertion that "Ruby is not something serious".
If you enjoy Perl, keep using it, man. Lots of ex-perlists are now doing ruby. Ask them why. You might want to control your tone though; ruby is what puts food on their children's table. You might not want to call it "not serious" on their face.
the O'reily nut shell book is the thinest book (even thinner than C++)
You're right, O'Reilly's C++ In a Nutshell is a mere 810 pages long, whereas their Perl in a Nutshell, 2nd Edition is a scant 768 pages.
When I think C++ and Perl, I think lean.
Light the blue touch-paper and retire immediately.
1. Ruby is not a toy not suitable for 'serious' programs, it's very similar to Python in fact, it's not as strong on science or math though as python because of libraries available in Python, if that's what you mean, say that, it's far more convincing.
2. Python could easily replace Perl for system admin tasks - come up with specific criticisms if you have met with any roadblocks - you would likely find similar problems with Ruby to Python if you somehow couldn't manage sysadmin or text scripting with Python.
3. Ruby, Python and Perl are actually quite interchangeable and could all be used for 'serious' tasks, or for short admin or text processing - all 3 are ideally suited to these things, and frankly the differences are not huge, Perl is slightly gnarlier, Python slightly stricter, Ruby slightly more anarchic, all 3 would get the job done easily.
4. WTF has Rails got to do with any of this? Troll much?
5. Why should we waste our time trying to convince someone with such trenchant and at the same time wildly inaccurate preconceived ideas?
(sorry if this is double-posted - slashdot is choking)
Perl is way faster. Like twice as fast. Check out my test:
% time (echo | ruby)
( echo | ruby; ) 0.01s user 0.00s system 91% cpu 0.016 total
% time (echo | perl)
( echo | perl; ) 0.00s user 0.00s system 84% cpu 0.007 total
Though this is ruby 1.9.3. I don't think 2.0 is twice as fast as 1.9.3.
But I've looked at ruby syntax a bit and it looks like it might have the advantage perl has for quick ad hoc text parsing but an overall cleaner syntax.
What I don't care a lot about is fancy pants modules like rails. If I want to do something serious there's python.
If you're happy shredding text with perl, I see no reason to change. If you're happy doing serious work with python, I see no reason to change.
Ruby is a, dynamic, duck-type OO language with closures, exceptions, and a debugger.
It has nice library infrastructure: http://rubygems.org/
It is generally a little less popular than Python and Perl, depending on your yardstick: http://www.langpop.com/
There are a few implementations of ruby, including one in java (with great bridging to java classes), one for iOS (with great bridging to iOS libraries), and one based on .net (with great bindings there). So if you have a particular target platform, one of those may interest you.
But here's the cononical answer to your question:
http://c2.com/cgi/wiki?PythonVsRuby
You might be interested in JRuby and Jython and their ability to communicate...
I code in Ruby for a living (Rails), and I think it's a really fun language. Which is something a fair number of rubyists say, and which is something you don't hear a lot of other folks say about their language of choice. For what that's worth...
I code in Ruby for a living (Rails), and I think it's a really fun language. Which is something a fair number of rubyists say, and which is something you don't hear a lot of other folks say about their language of choice. For what that's worth...
This. So much this.
Over the years I've used various languages to some degree... C, C++,Java, PHP, Perl.... and Ruby is simply the most fun and most expressive. I'll allow that all these languages have their strengths. (ok, not PHP). Python, too has many valid proponents and use cases, but I just can't have fun in a whitespace sensitive language. Java - I think is nice for people that like to type a lot. The modern day COBOL. But if IIRC, the fastest ruby interpreter is currently JRuby, so I can't entirely fault Java. C and C++ is obviously best for kernels and libraries where speed matters a lot, but obviously horrible for web application development.
For my own interests in web application development, Ruby on Rails is a sweet spot... I can make a lot of money doing something really fun. What's not to like about that?
Ruby has maths libraries (but not as extensive as Python here IMHO), threading, has had Unicode and UTF support for years (since 1.9), and has good support for the best scripting language UI if you ask me (HTML displayed in a browser with the built in web server). I suppose if your idea of 'serious programs' is desktop apps using the platform GUI through some glue code, then you're out of luck (frankly I wouldn't use Perl OR Python for that either, just use C, C++ and/or the platform language of choice). That's a silly definition of 'serious' though.
Re the speed and web toolkit, you clearly don't know what you're talking about there, plenty of options on Ruby, none of them obscure or difficult, and speed is pretty good nowadays, certainly good enough for almost all applications save extensive number crunching, it's really not a problem in the real world.
Pick your tools to suit the particular thing you're building (i.e. don't pick a scripting language to build a desktop app), but why limit yourself with silly misconceptions about tech? It's only a scripting language, comparable to many others and suitable for most of the same sort of problems.
Or just don't worry about flattering the ego of people so insecure and unskilled that they require you to pretend that Ruby is a widely used, mature, stable language.
You want the advice of someone who learns languages effortlessly, and therefore has no insecurity about anyone else's preferences or prejudices. Anyone who needs you to "control your tone" about a language "because it puts food on their children's table" - I fear for those children. And for anyone who gets advice from their parents, who apparently had to struggle a bit too much to pull themselves up to that competency and, fearing criticism of their precious, hard-won skill, give the impression of hanging on by their fingernails.
Ruby is indeed still at risk of being described as a toy language, and it is not nearly as commonly used as, say Perl, Python, Visual Basic, or even C#, let alone Objective C, C/C++ or Java, (as evidenced here) ...and the community is similarly small. Witness the hilarity around the recent Rubygems compromise to see the price of small size and lack of maturity. The language is still young, and messily and poorly specified, relying on a horrifyingly slow, rats-nest reference implementation for its definition, rather than a comprehensive design.
There is great cleverness in Ruby. It represents a ruthless preference for developer productivity over performance. An interesting experiment, but unfortunately it was done "by feel" rather than with any hard data about speed or defect rates given different design decisions. So, while some things about it are wonderful, other things only appear to be wonderful. On the whole you are unlikely to experience much net gain over Perl or Python, though you may enjoy the novelty of it. It's a fun language. By all means, try, and see for yourself. Just beware that you foreclose the ability to scale your work easily if you use Ruby.
Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told), many language features cause meaningful and irretrievable performance impacts that will never be ameliorated by runtime magic. It doesn't matter for many applications, but just something to keep in mind.
Tired of Political Trolls? Opt Out!
Python way is not too keen on conciseness to the point of unreadability - so it's not good for Perl-style one-liners. Ruby, on the other hand, retains a lot of Perlisms (like $_ etc) solely for that purpose.
Happy birthday to Ruby! Pretty cool the way that numeric coincidence worked out.
2.0 looks like a nice step forwards. I'm not sure where I stand on Refinements yet. I hate the method overriding of base classes that goes on in Ruby land, and Refinements is supposed to minimize the bad affects of that by offering scoped alterations, but from what I've heard there's a lot of side effects. Frankly, I think Ruby needs a 'protected' type; any other solution is just monkeys all the way down. But I could say this about a lot of the popular languages right now.
Java also sports the "everything is an object" mentality.
Say what?!?!?! Java explicitly distinguishes between primitives and objects! You can't send messages to primitives or literals in Java, only to objects and classes. Contrast with Ruby, where "5.times {p rand}" is a perfectly legitimate way to print five random numbers because the literal "5" is an Integer object which can respond to any message Integers implement.
Perl's speed is pretty similar to Ruby, it's nowhere near the Java VM nowadays, plus Ruby is available on the JVM if that's what you prefer to use. But the parent was talking about system admin scripts and little one liners run on the command line. If you're expecting them to be 'webscale' you're talking about something else entirely. I don't know about you but my system admin scripts are not expected to scale past the few machines I work on and run by precisely one user at a time, they're not user-facing scripts and therefore performance is not critical - they could be in any language really, I don't really use one-liners but it is quite possible to do them in all those languages, even Python.
Finally, re Twitter, if you try to reinvent a messaging server using a CRUD web app (a la twitter), you can expect all kinds of pain, even if you write it in enterprise ready Java in the first place. I imagine their problems were more down to entirely the wrong architecture, though now that they are one of the biggest sites on the internet, things like language choice will become very important for them. It's interesting though that a site like Facebook compiles PHP to C++ and then to one big binary in order to stay up and still use one of the slowest languages available - if they wished twitter could easily have done something simliar with Ruby or moved to using the ruby on the JVM, but the new people brought in to make it work were probably coming from Java backgrounds and as it need a rewrite, they thought why not, and why not indeed, it's worked out pretty well for them. They were still on Ruby 1.8.7 till the end I think, which was pretty insane given the improvements in Ruby 1.9 and points to serious problems with the older code.
So if I tolerate an additional 9 ms of startup time, I could write slightly faster interpreted code in a language with enough syntactic sugar to make mixing OO code with functional code less painful? Cool. ;)
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
And every primitive has a class version...
Which emphasizes the point - they are different things, or the duplication wouldn't be necessary.
...to which the primitives are automatically boxed when they need to be treated like objects.
Auto-boxing/unboxing is an unbelievably ugly kludge which exists specifically because Java distinguishes between primitives and objects. After enough programmers kvetched about the ugliness and extra code that was needed, Sun threw auto-boxing in somewhere around Java 1.4 or 1.5.
Languages with a true "everything is an object" model don't need such an awful hack. They also don't require umpteen implementations of containers or sorting (one for Objects and one apiece for each of the primitive types), with all the library bloat that entails. They don't need the programmer to be mentally tracking which elements are primitives and which are objects, and making sure to use the right constructs for each.
Python's not king of the one-line trick in the same way that Perl is
I know a lot of people one-line perl, but I never do. Every perl script I've ever written has been commented and readable and basically looked a lot like C without the torture. But I still have little interest in learning python and none in learning ruby, and what interest I have is based solely upon popularity.
Point is, that's not why python didn't get traction.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
in Ubuntu or Linux Mint or Debian, get the prerequisites
sudo apt-get install libyaml-dev ncurses-dev libreadline-dev bison libgdbm-dev libc6-dev libssl-dev libmysql++-dev libsqlite3-dev make build-essential libssl-dev libreadline6-dev zlib1g-dev libyaml-dev gcc
then download the ruby2 source from ruby-lang.org. then untar it and make/install it: ./configure
tar xvfz ruby-2.0.0-p0.tar.gz
cd ruby-2.0.0-p0
make
sudo apt-get install
see if it works:
ruby 2.0.0p0 (2013-02-24) [x86_64-linux]
"ruby is fun!"
"ruby is fun!"
I cited a comprehensive survey. You just talked about github. Yes, a particular open-source repository (Github) is popular among Ruby developers. The fact that you confuse this with language popularity is another hint about your critical thinking skills.
There is indeed economic merit in choosing developer productivity over runtime performance. However, there is no need to choose one or the other. Many other languages exist that are fine competitors to Ruby in terms of developer productivity, and most will not run as slowly. If you ignore them, your career will suffer.
I have invested many years in Ruby at this point, and I hope you can see that I am not unaware of its benefits. This is how I came to be in the position to scale Ruby applications, though of course, rather than have the droll exercise of being blindly accused of being "bad at it," I will refer you to the innumerable published experiences of famous Ruby developers who had to abandon the language due to scale issues. For theory, I will refer you to the excellent work of Charles Nutter, author of JRuby, currently among the best performing Ruby VMs, and far beyond Matz's work.
I have backed up every statement I've made, though if you feel that having a global interpreter lock is some kind of virtue, and does not reduce the scalability case of your language, you are stating something so extraordinary and beyond the pale of any conventional wisdom or common sense, it is upon you to prove it - to the astonishment of all, I assure you.
If you are getting by with forks and multi-tiered archtectures and high-open file limits and Passenger, I salute you. But if you really are this insecure and uninformed about Ruby, I suggest you learn another language - Groovy perhaps, or Python - or push yourself and learn Objective C or C++. Alternately, consider work on addressing the flaws in Ruby - your help is certainly needed, and you might give your beloved platform better hope for the future.
Tired of Political Trolls? Opt Out!