Ruby 1.9.0 Released

sciurus0 writes "The 1.9.0 development version of the Ruby programming language has been released. This version has many changes, including a new virtual machine that provides great speed improvements."

Comments

Benchmarks mean nothing, specially these ones.

[rgo]

Well, it seems that Ruby 1.9.0 is the fastest implementation available, it also is reflects the newest version of the language... but I would really like to see benchmarks based on real apps based on things like Mephisto,Radiant CMS and/or Mongrel. Also, does someone have a list with the most important features? The summary is way too poor.

Re:Why Ruby?

[Anonymous Coward]

Is there any reason why I should give Ruby a try?

Speaking as a ruby developer, if you're happy with python - not really! Python's also great. It's just a matter of which suits your style. Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable. So Python was just ruled out for me totally because of that.

Python and Ruby are both competing to be the most beautiful next-gen languages .. but beauty's in the eye of the beholder. I've found mine, and it sounds a lot like you've found yours. So .. that was the long way to say, again, "not really" ! : )

Re:Why Ruby?

[Anonymous Coward]

As someone in the same general situation as you -- I also work on Python code -- my conclusion when I asked myself the same question, was an emphatic no. There's little Ruby can do that Python cannot, and vice versa. As well, I looked through a Ruby tutorial; it can be a really strange language. I'm sure it works for people who put in the time to learn it, but it didn't click with my Pythonic mindset.

I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby. I resisted learning Perl in the first place and picked up Python instead; I have never regretted this decision, and I don't think I'll regret not learning Ruby either.

I'd like something else.

[jd]

Faster is good, but faster is not enough. Parallelization, these days, involves multi-LAN, multi-node, multi-CPU, multi-core systems where each core may or may not also be a vector processor. Modern libraries for handling such code tends to be usually too primitive to effectively handle anything but simple cases of even very narrowly-focussed software. If you want to parallelize across a combination of types, forget it. There are ways to do it - such as CORBA - but they're too slow and/or too complex. There are also languages modified to handle the complexities of parallelization, such as Unified Parallel C, Parlog or Occam, but they're usually much too complex to use in practice.

Is parallelization the only niche that isn't supported well? No. There are other areas languages generally do badly in. There are very few languages which handle internationalization efficiently. There are very few languages which handle graphical interfaces efficiently or logically. Languages are typically either good at handling very complicated data structures OR handling structures that are defined just-in-time, typically not both.

My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use.

Re:Scalability?

[JanneM]

Ruby is not a web development language. It is a general scripting language, like Perl or Python. You still seem to conflate the language with the specific use case of Rails - dynamic website scripting.

I use it heavily as my general scripting language; where I would have used Perl for small utilities, file munging or what have you before, I now use Ruby. Not because Perl is bad - it isn't - but Ruby really is in many respects Perl done right, with many of the benefits and without the syntactic quirkiness. Scaling just isn't a factor for most uses of a script language.

Re:Scalability?

[mindsuck]

Excuse me but http://www.ruby-lang.org/ runs on Radiant CMS, which is written in ruby, not on php.

Re:Scalability?

[mini me]

What inherit flaw in Ruby prevents it from scaling? Do keep in mind that performance and scalability are not the same thing.

Different style of programming

[Estanislao Mart�nez]

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

If you look at it from a features and libraries perspective, then you really won't find much different. But you shouldn't look at it that way.

There's a significant programming style difference between the Python and Ruby communities. Python programmers, as a general rule, tend to be more inclined toward imperative programming, while Ruby has much more of the feel of a multi-paradigm language. To understand a lot of Ruby code out there, you need to wrap your head around concepts like functional programming, metaprogramming, and domain-specific languages. Ruby code tends favor higher-order functional combinators over primitive looping syntax (an influence from functional programming), extending the system base classes extensively (an influence from Smalltalk), and a lot of it has the flavor of trying to extend the language to look more like the problem space itself (domain-specific languages; look at something like rake, for example).

Python aims to be "clean" in a very contentious sense of "clean." To put it in a way that will be taken very partisanly: Python is the language that you get when "clean and easy to understand" is taken to mean "only promotes the concepts that are easy to understand to a mediocre imperative programmer." For example, Guido is on the record that higher-order functions like reduce are supposedly hard to understand.

To be fair, yeah, Python is a reasonably clean imperative/OOP dynamic language, which is no mean feat, but many of us folks really would rather have a language that supports a broader range of programming paradigms. (Though I'm not as great of a fan of Ruby as I used to be before I got going on Scheme, I must say...)

Re:Why Ruby?

[Just Some Guy]

Ouch. Try this one:

>>> a
{1: 2, 'foo': 'bar'}
>>> b
{3: 4, 'foo': 'qux'}
>>> dict(a.items() + b.items())
{3: 4, 1: 2, 'foo': 'qux'}

It scales easily (add "+ c.items()" to mix in another dict) and doesn't have any restriction's on the keys' datatypes.

Re:Why Ruby?

[Yath]

Not true. Hash#clear and Hash#delete modify the object, but contain no suffix. I hate this about Ruby: you can't skim the method list for methods ending in "!". You have to also know if there exists a nondestructive version of it, and if you knew that, you'd already know its name.

You've got me there. Ruby could stand to clean up its act and be more consistent here. It still has quite an advantage, though.

Python: list(foo)
Ruby: Array(foo)
The real difference is that Rubyists will say "oh, but Array here is a method on Kernel, and methods with no explicit object get sent to Kernel". How this is different from global functions is beyond me.

As a Rubyist, I find the important question to be "is there a method to do this". In Ruby, if something can be made into an array, you use the to_a method. In Python, you won't be using a method. Ruby's Kernel.Array is an interesting bit of syntactic sugar (granted, Ruby has a bit much of that), but it isn't particularly relevant here.

Ruby also has << and %w (for multiple strings). While Ruby may have slightly fewer quote characters to learn, every one of them does something very different. In Python, IIRC, there's really only "single line" and "multi line".

The question, however, is why? Why do you need to learn more syntax to enter multiline strings?

I like Ruby, but you picked some of the weirdest (or falsest) reasons I could have imagined. How about symbols? How about blocks? How about everything being an expression? Open classes, method_missing, operators as simply syntactic sugar? Let's try to sell people on the *good* parts of Ruby. :-)

I've focused on my pet peeves: arbitrary syntax and broken paradigms. These things require a programmer to work harder. A language shouldn't do that. I believe that the power of open classes is important too, but I can't write everything.