Slashdot Mirror
Ruby 1.9.1 Released
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."
They don't need to be compettive on performance. They just need to improve performance to "barely tolerable slow" as opposed to "intolerably slow".
Too busy to just google for 2 sec before spouting off? .Net , or pure Ruby
Rubinius>Rubinius all aimed at among other execution speed.
Here is jRuby using java VM , Maglev using Smalltalk VM , IronRuby using MS
Help fight continental drift.
Python is skiing and ruby is snow boarding. One's more fun than the other but they are more similar than different.
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 may prove enlightening.
-- The act of censorship is always worse than whatever is being censored. Always.
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.
I still have more fans than freaks. WTF is wrong with you people?
Sorry it wasn't clear. No it is Ruby implemented to run on a Virtual Machine. You write your Ruby code as normal and it gets compiled to byte code that run very fast. This is how Java is fast. Ruby can in principle be as fast as Java. Ruby is not inherently slow just the current implementation is somewhat slow.
Help fight continental drift.
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.)
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.
Being bitter is drinking poison and hoping someone else will die
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...
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.
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 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
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.
John_Chalisque
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");
Being "roughly competitive" with PHP isn't saying much...
Like saying "I'm basically as knowledgable as Joe the Plumber"
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.
Karma: Excellent (My Karma? I wish...:-( )
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.
I am very small, utmostly microscopic.
you know, bad analogies are like a wooden banana.
...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: