Slashdot Log In
Ruby 1.9.1 Released
Posted by
kdawson
on Sun Feb 01, 2009 12:12 AM
from the yet-another-gem dept.
from the yet-another-gem dept.
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."
Related Stories
[+]
Technology: World's "Fastest" Small Web Server Released, Based On LISP 502 comments
Cougem writes "John Fremlin has released what he believes to be the worlds fastest webserver for small dynamic content, teepeedee2. It is written entirely in LISP, the world's second oldest high-level programming language. He gave a talk at the Tokyo Linux Users Group last year, with benchmarks, which he says demonstrate that 'functional programming languages can beat C.' Imagine a small alternative to Ruby on rails, supporting the development of any web application, but much faster."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
hmmm... (Score:3, Funny)
No wifi, garbage collection not as good as Lisp; Lame.
Re: (Score:2, Informative)
No wifi, garbage collection not as good as Lisp; Lame.
Why was this modded as flamebait? And what's that WOOSHing [slashdot.org] sound?
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: (Score:2)
My company tried to make the switch and could find enough developers, could find enough module support and just couldn't get the same functionality for RUBY as with languages that have larger communities. Plus under large loads, it
Re: (Score:3, Interesting)
You do realize neither Ruby nor Rails is an acronym, right? Ok.
The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
And those don't compare well [slideshare.net], even to Rails, certainly not to Merb.
And Merb is going to be merged into Rails.
under large loads, it buckled
Hardware is cheap. Couldn't you throw more at the problem?
Re: (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, bu
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.
Parent
Re: (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: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.
Parent
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.
Parent
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.
Parent
Re: (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 inh
Re: (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
Re: (Score:3, Interesting)
To date for alot of people and companies, RUBY was hype (and this has alot to do with the community that hyped it). Now th
Re: (Score:2)
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
If you see no advantages to using it over PHP, you obviously haven't looked very hard.
Off the top of my head: Ruby has better syntax, a better object model, runs faster (really [slideshare.net]), better standard libraries -- Rails aside, Ruby tends not to pollute the global namespace with bullshit like mysql_escape_magic_quotes_no_really_I_mean_it_this_time...
PHP's advantage? Lots of unimaginative programmers like you know it, and it's slightly better at mixing code and data, since it's really just a Turing-complete templat
Re: (Score:2)
I have now seen the video you linked to, and I can't noticed where he said Ruby lack direction. He said in fact that Ruby is great as it is, what he want to see however, is that new ideas for Ruby experimented on as forks rather than tried within the mainline Ruby. I think the video was quite good and worth seeing even though it last 47 minutes!
The parent I believe is incorrect in using that video to claim there is a lack of direction.
Unicode? (Score:5, Interesting)
A lot of work also went into encoding awareness of strings
That's quite a fancy way to say "a lot of work went into making dealing with strings and encodings as messy as possible".
So far, Ruby 1.9/2.0 is the only high-level language I know of which allows strings within the same program to be in different encodings (attaching a reference to encoding to every string). For double fun, the encodings need not be compatible with each other (not even with Unicode). This might also make Ruby the first language in which string comparison and concatenation are not well-defined for two arbitrary strings (as you get an exception if encodings are incompatible). Just wonderful - imagine writing a well-behaved library which does any sort of string processing with input parameters with these constraints...
Re: (Score:2)
Cocoa and CoreFoundation, though not as high level, do something similar.
Re: (Score:3, Interesting)
Perhaps you need to spend time trying more languages; you'd learn not only that other languages have done this, but that many of them later rejected the idea and moved to, typically, a pure Unicode string type with a separate non-string type for working with sequences of bytes in particular encodings.
Re:Unicode? (Score:5, Funny)
Php also allows strings to use different encodings within the same program. With the extra twist that php don't keep track of the encoding, so if you want to find the number of characters in a string, you the developer must know the current encoding of the string, and then call the right method, based on which encoding the string has.
Sometimes I think that the developers of php just take all the bad things in other languages, and say "I can make a worse implementation of this."
Parent
Re:So? (Score:4, Interesting)
An ASCII string can be mapped to a Unicode string. For each byte in an ASCII string there is a matching Unicode symbol.
How should string compare work? Well for simple ==, I think it should fail if the encodings are different, as they really are different. It can also fail if the two strings encode the same Unicode but in different ways (this is possible in some encodings).
There can however be a more complex call that converts both strings to Unicode and compares them. One huge problem with most current imlementations, including Python, is absolutely brain-dead (and "politically correct") handling of invalid UTF-8, where invalid encodings throw errors, which makes use of UTF-8 actually impossible for non-trivial programs. Instead it should never throw errors. Error bytes should represent something unique in Unicode, one popular proposal is U+D8xx (which is also an "error" in UTF-16).
A problem Python (and a lot of other programs have) is that they think "Unicode" means "some sort of encoding where each Unicode symbol takes the same space". This requires 21 bits per symbol, the only practical way to support this to use 32 bits. Almost immediatly they run into difficulty in that Windows uses UTF-16, so they punt and use UTF-16, basically abandoning their entire idea. They should instead use UTF-8 which has enormous advantages: UTF-8 errors are not lost and can be translated differently when finally used (ie for display turning them into CP1252 is better, but for a filename turning them into the above error codes is better), all other encodings (which are byte based) can be stored in the same object, and no translation is needed when you load UTF-8 data. Also UTF-16 (including invalid UTF-16) can be losslessly translated to UTF-8 and back, so there is no problem supporting Windows backends either.
Parent
Re: (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 a
Re:Twice as fast... (Score:5, Funny)
They don't need to be compettive on performance. They just need to improve performance to "barely tolerable slow" as opposed to "intolerably slow".
Parent
Re:Twice as fast... (Score:5, Informative)
Here is jRuby [codehaus.org] using java VM , Maglev [gemstone.com] using Smalltalk VM , IronRuby [ironruby.net] using MS
Parent
Re: (Score:2)
Re:Twice as fast... (Score:5, Informative)
Parent
Re:Twice as fast... (Score:5, Informative)
JRuby is an interpreter, written in Java. It does not compile Ruby to Java bytecode.
Incorrect. I certainly DOES compile Ruby to Java bytecode. Read the blogs of Charles Nutter, John Rose and Ola Bini for more information.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
So in other words... if you want something decent and fast, use Java???
Pretty much, yes. Welcome to the 21st century.
Ruby/Python in JVM/CLR not a Silver Bullet (Score:4, Informative)
The typical situation is that something like JRuby or Jython are implementations of a dynamic language in Java/C#/etc. instead of in C/C++, but they have the same architecture as the C/C++ engines. This leads to about the same performance - the Java VM does excellent JITing, but as we know, it brings Java into about the same area as C/C++, not faster.
So, these implementations end up being about as fast as the original C/C++ ones (but they have various other advantages, which are their real value).
The latest-generation JavaScript engines - and we are talking about the last 6 months here! - are very different in their architecture. They use techniques like trace trees and hidden classes, along with native code generation using JITs specializing in JavaScript, to generate performance that can, in some cases, be closer to C/C++ than to Python/Ruby.
The PyPy project has been saying this all along, in fact - that to make dynamic languages fast, you can't just implement them in the JVM or such and expect 'magic' to happen with that VM's JIT. It doesn't work that way. Even if you JIT an architecture that does hash table lookups or type checking for each assignment, performance will be poor; the JIT can't fix your algorithm. Fixing the algorithm is exactly what latest-generation Javascript engines like V8 and TraceMonkey do.
Parent
Re:Twice as fast... (Score:4, Insightful)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=php [debian.org]
Parent
Re:Twice as fast... (Score:4, Funny)
Being "roughly competitive" with PHP isn't saying much...
Like saying "I'm basically as knowledgable as Joe the Plumber"
Parent
Re:Twice as fast... (Score:4, Informative)
You know, you have a point. I think all dynamic languages could probably learn something from the recent Javascript speed-up projects...
Except Ruby isn't slow [slideshare.net].
And yes, I am happy about it being twice as fast, because it was already fast enough.
Parent
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.
Parent
Re:Twice as fast... (Score:5, Informative)
I still do Perl.
Half the reason is that Perl is a bit insane and breaks all language design rules -- but still works. That makes it fun. The other half is that the community is so good; CPAN is a result of that and, also, you don't have so much of that disgusting hype (like you just commented on); like you, I'd rather not be identified with a community doing that.
Ruby do look sweet and Python seems usable (if a bit boring). But with the "Perl Best Practices" book becoming so popular and Moose (et al), I can't motivate a switch. The largest problem with Perl today IMHO is that it takes a bit more time and energy to learn.
Parent
Re: (Score:3, Interesting)
Except that slideshow is comparing the performance of popular frameworks for different languages.
I believe it also does a comparison of a raw Rack request versus a non-cake PHP page.
I won't try to handwave away its faults.
Neither than I -- only pointing out that most people aren't even doing benchmarks. It's just accepted that "Ruby is Slow". I'm not saying it's fast, but I am saying that when you say things like this:
We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial. They'd also be great to establish this point:
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.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and t
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.
Parent
Re: (Score:2, Funny)
all of them?
Re:Ruby vs Python (Score:4, Insightful)
Parent
What about C? (Score:5, Funny)
Python is skiing and ruby is snow boarding.
I guess that makes C drunk driving. Much faster and more crash-prone.
--*car_analogy_quota("jonaskoelker");
Parent
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.
Parent
Re:Ruby vs Python (Score:5, Funny)
you know, bad analogies are like a wooden banana.
Parent
Re: (Score:3, Informative)
Re: (Score:2)
That doesn't do the same thing at all, and won't do the same thing in the incompatible Python 3 as in Python 2. The Python equivalent to that Ruby would be:
for i in range(1,11): print i
The Python is more readable, but the operation of Python's range(1,11) is a bit less obvious than Ruby's (1..10).each IMO.
Re: (Score:2)
Ruby uses explicit 'end' to mark blocks, Python doesn't. Ruby uses OOP for pretty much everything while Python doesn't (i.e. [].length vs len([], [1,2,3].each{|i| ...} vs for i in [1,2,3]:). Python follows a philosophy of doing something exactly one way, while Ruby doesn't have a problem allowing multiple ways to accomplish the same thing. Ruby uses $ to mark global variables, @ to mark member variables, Python uses explicit 'self.' to do it.
Overall however they look and feel pretty similar.
Re: (Score:2)
Big disclaimer: Perl does as well. Ruby differentiates itself here by disallowing infinite ways.
Re: (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 t
Re:Ruby vs Python (Score:5, Informative)
...snip...
Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):
You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).
From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).
This also reveals a few interesting points of Python/Ruby comparison:
Parent
Re:Ruby vs Python (Score:5, Interesting)
Ruby is meant to be more comfortable and expressive in the hands of a programmer than Python. That means more power and more elegance, but also less regularity, more features, and more emphasis on conciseness instead of readability and learnability. (Python is surprisingly readable for non-Python programmers, which I have found handy more than once.)
Personally, I use Python at work because I'm terrible at remembering linguistic features and syntax. At work almost every neuron in my brain is devoted to C++, so for everything else I need a nice, simple, even stupidly simple language that complements C++. Plus if someone inherits my Python code and says *gasp* "But I don't know Python!" I can honestly say, "Don't worry, you have nothing to worry about. You can learn it in a couple of days."
People tell me Ruby is more natural and expressive, and I believe them, but if Python ever lets me down I'm skipping straight to the Red Pill, aka Lisp, which I have enjoyed recreationally on occasion. (I keep some spare neurons for myself for fun. Don't tell my boss.)
Parent
Re:Ruby vs Python (Score:5, Interesting)
Here's my take, having used both languages in anger. First off, let me call out a number of similarities between these languages. They're both OO, dynamic, and provide reflection capabilities (useful for meta-programming). They've both been influenced by functional languages. They both have active, vibrant user communities. Both have many open-source and shipping commercial applications that leverage or are fully built on these languages. While there are notable syntactic differences, I find that there's a certain shared "feel" between Python and Ruby.
Now I'll call out the differences I find interesting. Python's import model (akin to #include for you C folk) is stronger than Ruby's require when it comes to larger applications. By "stronger", I mean that it's more explicit and therefore provides greater assurance against unintended effects from referencing a different module/class/object than you intended. This is a two-edged sword, since Ruby's code loading approach is less verbose and affords the construction of tools like Rails' Dependencies module which automatically finds code via a convention-over-configuration model. (e.g. calling require is never needed for the main application code of a Rails application if you just follow the file vs. class naming conventions -- this is *very* handy, IMO.)
I'm big on powerful abstractions in programming languages. On this count, I find that Ruby wins hands down. The Python community has had a muddled approach to some key areas that Ruby had early clarity on via lessons learned from Smalltalk. Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python. Blocks are nothing more or less than anonymous functions, aka "lambdas", but their beauty lies in their syntatic integration. Consider the Ruby iterator pattern:
... end construct is a block. a is a Ruby Array object. The conventional iterator method each calls the block once for every element in order, as you'd expect. The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable [ruby-doc.org] on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
a = [3,4,5]
a.each do |x|
puts x
end
The do
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer. Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
class File
def File.open(name,mode)
file = File.new(name,mode)
if block_given?
begin
yield
ensure
file.close
end
else
return file
end
end
end
And the list of uses goes on and on. Blocks are a foundation component that makes Ruby well-suited for writi
Parent