Ruby 1.9.1 Released 226
Janwedekind writes "Yuki Sonoda yesterday announced the release of Ruby 1.9.1 (Ruby Inside coverage with lots of links). The VM of Ruby 1.9, formerly known as YARV, was initiated by Koichi Sasada and has been in the making for quite some time. Ruby's creator Yukihiro Matsumoto has already presented many of the upcoming features in his keynote at RubyConf 2007. Most notably, Ruby 1.9 now supports native threads and an implementation of fibers. A lot of work also went into encoding awareness of strings. The 1.9.1 version is said to be twice as fast as the stable 1.8.7. It will take some time though until the majority of existing Ruby extensions get ported to 1.9."
I am afraid, there is lack of direction for Ruby (Score:2, Insightful)
According to this video [confreaks.com], there is lack of direction. This is by Dave Thomas [wikipedia.org], and important figure in the Ruby world.
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
Re:Ruby vs Python (Score:4, Insightful)
Re:I am afraid, there is lack of direction for Rub (Score:5, Insightful)
Choice of programming language actually matters, and dismissing languages you haven't used much is foolhardy. If this isn't obvious to you, this article [paulgraham.com] may prove enlightening.
Re:I am afraid, there is lack of direction for Rub (Score:5, Insightful)
No, it really doesn't. What matter is availability of libraries, and your personal profficiency with the language. Given C and a regex library, I'll write better, cleaner, and faster doing string parsing than I would in perl. Why? Because I've used C and C++ every day for the past 8 years. Even though I use and know perl and regex is built into the language, I make more mistakes in it due to using it only a few times a year. And yes, I've actually tried this- I was 5x faster in C with the regex library. Do the test again with a perl maven, and I'm sure the opposite result would occur, even if you gave a problem that's more traditionally a C thing.
Now there are some languages that better suit individual people than other languages, due to the way they approach problems. Lisp is good for people who think very mathematically. C is good for those who think in a very step by step manner. OOP is good for people who think in terms of models and interactions. But you'll always be more efficient in a language you know well than one thats new to you.
Which isn't to say there's no reason to learn a new language- you may find one that fits you a bit better, especially if you learn a new paradigm like functional. But you'll never solve a problem quicker by using a language you aren't as familiar with, unless a library for a major piece of functionality exists in that language but not yours.
Re:I am afraid, there is lack of direction for Rub (Score:3, Insightful)
Hardware is only cheap if someone else is paying for it. Why spend money you don't have to? AMazon and other big companies have already come to that realization. When I worked there a year or so ago it was impossible to get new hardware- not because they were cheap, but to encourage you to use the hardware more efficiently. The end result- a lot more use of virtualization for small stuff, a lot more thought into efficiency of services, and millions saved. Smaller organizations won't save millions, but they'll save a significant chunk of cash. The "just throw money at it" attitude is gross negligence.
Re:I am afraid, there is lack of direction for Rub (Score:3, Insightful)
That approach makes sense for small jobs, but for projects that take more than (say) two months, it makes more sense to choose a roughly suitable language, even if your proficiency is lower.
Also, for any code that isn't throwaway code, you have to assume that some unknown person will eventually inherit and maintain your code. Under that assumption, it's more important for the language to be appropriate for the task than for the language to be convenient for the initial programmer. You wouldn't want to inherit a bunch of string parsing code written in Fortran, would you? At least choose a roughly suitable language! Even the best imaginable regex library for C has to be relatively crappy (measured by the readability and correctness of code that uses it) just because of the limitations of the language.
Now, I personally detest Perl and am pretty good with C++, but if somebody proposed writing a string parsing program in C++, I would tell them to use whatever non-dead scripting language they know, even if it's Perl, and if they don't know one yet, for God's sake pick one and learn it -- even if it's Perl!
Re:Twice as fast... (Score:3, Insightful)
So in other words... if you want something decent and fast, use Java???
Pretty much, yes. Welcome to the 21st century.
Re:Twice as fast... (Score:4, Insightful)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=php [debian.org]
Re:Twice as fast... (Score:5, Insightful)
Except that slideshow is comparing the performance of popular frameworks for different languages. So they're showing that Rails is an efficient framework. That's a perfectly valid point to make (the language makes it easy to write a better algorithm, or maybe the framework is just more efficient), but it doesn't say anything about how fast the code is executed.
I switched from Perl to Ruby as my everyday sysadmin and glue language, and I use it pretty extensively. I love Ruby, but I won't try to handwave away its faults. In my usage, it's undeniably, dramatically, slower than Perl. We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
A script to parse a huge, complex data file sucks ten times as many CPU cycles to do the same work. For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
Re:I am afraid, there is lack of direction for Rub (Score:3, Insightful)
Your maintenance point is good. For that reason alone I wouldn't use C for a web front end (back end service sure, not a front end), because the vast majority of people they'd hire to maintain it wouldn't be experts in it. And for any team project its not your best language that matters, but the best language of the team as a whole.
I disagree with your time argument though. If anything, the time just makes it more important to use what you're familiar with. If you're talking about something taking 1 hr vs half a day based on language choice, its a minor difference. If you're talking about a 3 month project, you're probably talking 2-3 months extra to use a less familiar language.
Re:I am afraid, there is lack of direction for Rub (Score:4, Insightful)
Hardware is only cheap if someone else is paying for it.
No, hardware is cheap, relative to programmer time. Moore's Law only reinforces this. In fact, you're making my argument for me:
Why spend money you don't have to?
Let's suppose it takes me half the time to code it in Rails than it does to code it in PHP, but requires twice the power to run. And let's suppose I make minimum wage.
Before it even comes close to costing more to run the hardware than it does to run my salary, you're already running six or seven extra-large instances. Go look up the specs for an extra-large instance. And keep in mind, that's additional -- that assumes the optimized version requires six or seven of those, and my inefficient version requires six or seven more.
You can run the numbers yourself, but it ultimately tends to work out the same. And all of that assumes the Ruby version is slower -- and, following my link above, it really isn't.
Smaller organizations won't save millions, but they'll save a significant chunk of cash.
Smaller organizations, I would think the "just throw hardware at it" argument makes even more sense. The speed of a nonworking app is irrelevant. The speed of an app serving a dozen programmers and testers, before public release, is similarly irrelevant. By the time you're getting hundreds or thousands of requests per second, you're probably making enough money from ads alone to cover the costs -- but while you're still "only" getting dozens of requests per second, a single Rails server might work just fine.
Now, I agree, throwing hardware at it is not a good long-term solution. The good long-term solution is to optimize the better systems. However, investing in a demonstrably worse architecture to gain a little performance -- maybe -- in the short term, does not seem like a good move.
Re:Twice as fast... (Score:5, Insightful)
It has always been 'fast enough' for appropriate programming problems. If Ruby is too slow, you're in the wrong problem domain to use Ruby.
Note that there is, and can never be, OneTrueLanguage(TM).
Efficient development is all about playing to the advantages of the development tools available to you. Complaining about weaknesses is usually indicative of a lack of understanding.
Re:I am afraid, there is lack of direction for Rub (Score:3, Insightful)
How do you know the tons of manhours put into optimization work won't cost you more than the added hardware?
Re:Ruby vs Python (Score:3, Insightful)
[ruby is more OOP than python:] [].length vs len([]), [1, 2, 3].each vs for i in [1, 2, 3]
Given my understanding of OOP, those are not particularly good examples.
len([]) is equivalent to [].__len__, a method invocation on the object in question. Different classes can define different __len__ methods.
for i in some_object calls some_object.__iter__ behind the scenes; same thing again: a method with different definitions across different classes.
What defines OOP is not where you put the dot, but what the dot means, which roughly speaking is the method lookup in a vtable. Ruby and Python both do that, so they're both OO. Python just puts a little syntactic (and semantic) sugar on it.
Something I'm more likely to agree with: Python and Ruby are both more OO than C++ with respect to the collection classes.
Why is that? Because (for example) vector.size and set.size aren't overridden versions of (a hypothetical) collection.size.
In Haskell parlance (note: "class" means two different things in C++ and Haskell), the code
...
template <T> int foo(const T& t) { return t.size(); }
uses class-bound polymorphism with inferred classes. Meaning that the set of types T for which the code is valid is the class of types that have a size method. The inferred-ness (roughly speaking) means that you don't write template <T extends has_a_size_method>
If you still believe Ruby is more OOP than Python, could you point out either (1) another example, or (2) why you disagree with my thinking?
I hope one or more of us can learn something from this discussion :)
Re:Ruby vs Python (Score:5, Insightful)
One has to wonder if you actually ski or snowboard. Other than the fact that they are both done on snowy downhill slopes, there is no similarity.
Re:Twice as fast... (Score:3, Insightful)
Re:I am afraid, there is lack of direction for Rub (Score:4, Insightful)
> Besides, inefficient code will add up almost exponentially as your load increases.
Eh?
We're not talking about poor algorithm selection. We're talking about using a slower language rather than a faster language. Unless you deliberately adopt a "slower languages deserve slower algorithms" mentality, you're talking about a linear increase in hardware.
In that case, doubling the hardware requirements in exchange for even a 25% cut in coding time is going to be a huge boon for your company. If writing in a cleaner, more elegant language makes the code base smaller and easier to read, those senior developers are going to have a much easier time finding the bugs and the bottlenecks. Plus, if you can write the thing that much faster, your developers are going to have a lot more fun.
Since we're talking specifically about Rails here, the first optimization pass is usually A) finding pages and partials that can be cached, and B) tweaking your ActiveRecord queries so that the database grabs all the records it needs on the first pass. Both are simple to do, and once you've accomplished them it's going to be quite a while before a normal site is going to run into scaling issues.
Re:Unicode? (Score:3, Insightful)
I think 90% of users will end up with Unicode, and different encodings are importand only in some countries and in some usages (like Japan).
As I used 1.9 a little, and also strings, I can't see this is being a mess or introduces incompatibility.
The whole multi-encoding system was introduced into Ruby, supposedly, to handle those "some countries and some usages". The problem is that it is very hard to write reusable libraries which actually live up to it when there's no guarantee about any input encodings. Say my function gets a string; what operations can it safely do with it? What if it gets two strings from different sources? What if it also gets a text stream? If you've read the Ruby 1.9 mailing list, you'd probably seen Tim Bray's complaints about how tricky it is to e.g. do XML processing that way (XML mandates Unicode).
I agree that in practice, most likely, everyone will just ignore this whole mess and use Unicode throughout, and libraries will be written to assume that all input strings are Unicode. But then, why introduce all those complications in the first place? If non-Unicode strings are going to end up being second-class citizens anyway, wouldn't it make more sense to make them a distinct type, and their use explicit, just like every other language had done it?