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."
No wifi, garbage collection not as good as Lisp; Lame.
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.
that is asking for a bloody long post that will boil down to. The ruby syntax is cooler yet more obscure, the vm is slower but just because there is less money behind it. It must be nice to have a big company like Google behind you. *scoffing at the php fans and their Zend touting* (PS, im a python fan) when I say that the syntax is cooler, i give the example that the for loop is implemented as a call to an iterator so you get this http://refactormycode.com/codes/2-ruby-simple-loop.
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?
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.
And yes, I am happy about it being twice as fast, because it was already fast enough.
Don't thank God, thank a doctor!
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...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=php
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.
I am not familiar with Rubinius. But regarding all the others - Ruby on Java, on the CLR, etc., none of those are anywhere close to approaching the speed of recent JavaScript engines.
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.
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
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.
Don't thank God, thank a doctor!
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:
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.
> 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.
You want the truthiness? You can't handle the truthiness!