Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming

Ruby 1.9.0 Released 199

Posted by timothy from the facetnating dept.
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."
This discussion has been archived. No new comments can be posted.

Ruby 1.9.0 Released More

Ruby 1.9.0 Released

Comments Filter:
  • Why does this look like an unedited blurp from the Firehose?
  • 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.

  • 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)? Basically, I've been using Python for quite a while and work with a largish codebase at the office. Is there any reason why I should give Ruby a try other than the standard - and very valid - "because it's there"? From what I've heard it seems that the two languages occupy roughly the same niche and are

    • Re:Why Ruby? (Score:4, Insightful)

      by Anonymous Coward on Tuesday December 25, 2007 @11:02PM (#21818760)

      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" ! : )
      • Yeah, same here for why I don't like Python.
        I find myself adding additional if/loop statements around a block of code often enough that I just couldn't imagine working with python where it isn't trivial to automatically indent the block of code, since the indent is the block of code. Copying/pasting code is another case where the indentation is not necessairly correct. I am not talking about duplicating code here, but something like taking a chunk of code and making it into a function call.

        I really like how

        • I really like how quite often the single-line if/then statements in Ruby could be read aloud directly and they would make sense

          I don't like Perl so much anymore, but it had a really cool feature where instead of writing "object.method(args)", you could write "method object args". Instead of a construct like

          if not value: output.log("value isn't set")

          you could write

          log output "value isn't test" unless value

          It was kind of a pain in the ass for maintenance because if you want to change the test for value from false to true, you'd have to re-write that as "unless not value" and mentally parse the double-negative each time,

          • Re: (Score:2)

            by nuzak ( 959558 )
            > I don't like Perl so much anymore, but it had a really cool feature where instead of writing "object.method(args)", you could write "method object args".

            This is called "indirect object" syntax, and it's really frowned upon in modern perl code due to the ambiguities it causes. Construction with my $x = new Foo was one of the last holdouts, but even that has largely given way to my $x = Foo->new.

          • Trailing 'if' as a statement modifier works just as well as trailing 'unless' does. :s/unless/if/

            That's not so hard in a proper editor. I'm sure Emacs has its own sensible way to replace text, too.

      • Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable

        Agreed! Why in the *hell* in the 20th century should I worry so much about spacing? Let the editor handle that for me. Python developers have to create all sorts of tricks (emacs bindings mostly) to work around this flawed design just to work with the language. Frankly no modern language should have 'column' constraints.

        Fortran is dead! Long live Python!

    • FFI (Score:3, Funny)

      by r6144 ( 544027 )
      Back then Ruby's C interface appeared much easier to use than Python's reference-counting mess (I don't know about recent developments). Apart from that, both are good as far as scripting languages go.

    • Re: (Score:2, Insightful)

      by 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 ve
    • Answer: No. Ruby doesn't scale as well as PHP, Python, or PERL. The number of responses per second it can handle quickly drops off in comparison to the other languages; tack on Rails and it's even worse. Honestly, any MVC framework in Perl, PHP or Python is going to be more scalable and faster than RUBY; it may have a bit steeper of a learning curve for a newbie but so what.
      • I'd like to see some statistics backing up this claim with code samples. I have never seen a performance problem in Ruby or any other language that was not fixed within an hour by generally simple code improvements. The developer is the cause of 99% of performance problems in any mainstream language today.
        • Tell it to the ruby.com or rubyonrails.com websites. Tell it to 43things. They all rely upon PHP to scale their sites. This is a well known fact stated over and over again and that the RUBY maintainers are aware of but that the RUBY community calls a flame or FUD. Test it yourself if you think it's a lie; check those sites yourself if you think it's a lie (Note: some of the RUBY sites have turned 'show PHP' off in their php.ini config so it may not be showing anymore in Netcraft or with PHP hidden cookies b

          • Tell it to the ruby.com or rubyonrails.com websites.

            Are you perhaps thinking of ruby-lang.org? Ruby.com has nothing to do with the Ruby language.

            They all rely upon PHP to scale their sites. This is a well known fact stated over and over again and that the RUBY maintainers are aware of but that the RUBY community calls a flame or FUD.

            IIRC, ruby-lang.org used PHP before Radiant CMS was developed, and rubyonrails.(org/com) uses, or used, PHP for some peripheral roles, but is mostly (maybe entirely now) Rails.

            • Evidence? sure... here you go. Here's a prime example. http://shiflett.org/blog/2006/feb/php-easter-eggs [shiflett.org]

              If you can no longer see them it's because they have show_php turned off in their php.ini. You can still spot what they are running on Netcraft and ask them why they are running PHP and they will tell you; they have responded in the past to such inquiries with what I am telling you.

              • You can still spot what they are running on Netcraft

                Yes, I can. And when I do, I find that contrary to your claims, neither the Ruby language site (which is www.ruby-lang.org, not www.ruby.com) nor 43things.com is running PHP. Rubyonrails.(org/com) is. www.ruby.com doesn't show PHP on Netcraft either, but isn't really relevant to the Ruby programming language in the first place.

                and ask them why they are running PHP and they will tell you; they have responded in the past to such inquiries with what I am tell

                • As stated, in the php.ini, you can turn 'show_php' off. You can state that I am wrong all you want but the cookies used to show (and in some cases still do), with a TINY amount of legwork, you will find that they still DO run PHP and if you ask them directly, they will state as much.

                  I'm constantly amazed at the state of denial in the RUBY community when even the maintainers state that they use other languages that their commnity just puts their fingers in their ears and starts going 'LALALALALALA I CAN'T H

                  • As stated, in the php.ini, you can turn 'show_php' off.

                    You stated specifically that one could verify that those sites were running PHP with Netcraft. Checking Netcraft shows that you are wrong for all but one of the three. You stated specifically that the reason those sites gave for using PHP was scalability. The one site that uses PHP (rubyonrails.org), in fact, gives an explanation that has nothing to do with scalability.

                    You can state that I am wrong all you want

                    Yes, I can. And I'll be right, because yo

                    • I provided plenty. You Only want to see what you want to. If they shut off php.ini, and you don't wish to do your own legwork outside of this tiny little forum, then you don't truly wish to know now do you. You only wish to argue. To that I say feel free to remain ignorant. I have given you the key to free your mind... it is up to you to remain caged or not.

    • Re:Why Ruby? (Score:5, Interesting)

      by Tyler Eaves ( 344284 ) on Tuesday December 25, 2007 @11:15PM (#21818846)
      Ruby is a neat language. Basically imagine a language that can do all of the great hacks you can do in perl (and then some) but with a sane syntax. Python is a very very good language, I've written quite a bit of code in it. Ruby is nicer, at least from a syntax standpoint. It's just SO expressive, even beating python. But, at least until now, the speed always SUCKED balls. Maybe this new release will get it roughly on par with python.
      • If performance is an issue, don't you move the code to something in a compiled langauge once a) the requirements are settled and b) you're sure you actually need to do so?
        • Hah! This troll comes up time and time again. Let me know when you get (a) - I want to prepare for the end of the world that will surely follow...
          • It's not so much a troll as an observation that the usual complaints about performance and scripting languages are, themselves, the troll.
            I work with a large number of folks who don't seem to think that anything useful can be done unless it's done in Java, irrespective of the number of worked counter-examples presented.
            • But you can't simply brush off performance concerns as a non-issue simply because some folks have an impression that all scripting languages are slow. Performance is always a concern. And it sounds like Ruby has had real performance problems that need to be addressed, and it sounds like they are.

              It's trollish to claim that requirements have ever been completely defined, and that development is ever actually finished (you never finish, you simply pick a time to 'stop' writing more). Though perhaps 'fla

              • I never said you can brush off performance. My contention is that, in the overall priority of concerns, performance sorts lower than many claim.
                Your point that it is trollish/flamebait to claim that requirements are ever completely defined is well taken, but actually argues in favor of a scripting language like Ruby. The fatter runtime supports a more flexible approach to following those flexible requirements, especially when the customer can't differentiate between his bottom and a hat rack. (Oh god, th

    • Re:Why Ruby? (Score:4, Informative)

      by sciurus0 ( 894908 ) on Tuesday December 25, 2007 @11:17PM (#21818860)

      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)?

      Take a glance at Ruby from other languages [ruby-lang.org]. This page highlights some of the things that make Ruby Ruby.

    • Re: (Score:2)

      by PaulK ( 85154 )
      Try it if you can find the time, and maybe pick up a copy of Ruby for Rails [amazon.com].

      Python currently has larger library support.

      Personally I see no need for you to reinvent your wheel, but you'll probably not be gratified as to the validity of your decision until you dig a little.

    • Re:Why Ruby? (Score:4, Interesting)

      by Yath ( 6378 ) on Wednesday December 26, 2007 @12:16AM (#21819150) Journal
      Ruby has some differences that are important to some people.

      * The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together. This doesn't work well in Python, because methods frequently act like "procedures", modifying the object and returning nothing. Sometimes, Python programmers work around this by explicitly copying objects and then calling such methods. Other times, modifying the persistent object is just what they wanted; in Ruby, you would use a method which ends in "?", which is how Ruby identifies (by convention) methods that modify the object.

      Thus, to combine two dictionaries in Python, without modifying either of them:

        dcombined = d1.copy()
        dcombined.update(d2)

      In Ruby:

        dcombined = d1.merge(d2)

      Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.

      * It's entirely predictable whether a built-in class's method will modify the object, because of the "?" suffix convention. In Python, you don't have such an explicit convention, which can sometimes make more work for the programmer.
      * Ruby doesn't rely on global functions as much, or "builtins" as they're called in Python. If you want to know the length of something, or convert a string into a list of characters, you call a method of the object rather than a global function. Some people find this to be easier, given that you only need to focus on one paradigm (object-oriented) and not two (e.g., object-oriented and imperative).
      * The print statement in Ruby prints only what you tell it to, rather than adding whitespace in various cases. Since this is the behavior of print or printf in most languages, this is nice. Ruby offers the puts method for those times you want whitespace helpfully added (like Perl 5.10's say).
      * regular expressions are more tightly integrated. Some people consider this a disadvantage of Ruby though, because you can write less explicit code.
      * Ruby gives you fewer types of quotes to learn, because ' and " are multiline.

      • Re: (Score:3, Informative)

        by eosp ( 885380 )
        I thought that the ? suffix meant "this makes no modifications and only returns a certain property, usually boolean" and ! meant "this modifies the "self" object. Example: foo.gsub!(/f/, 'g') would modify 'foo' directly, where foo.gsub(/f/, 'g') would return a new string but leave the old one unmodified.

      • Re: (Score:2)

        by Haeleth ( 414428 )

        The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together.
        [...]
        Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.

        This is indeed a useful feature, but it's not really functional programming, just a different style of object oriented design. The complete absence of any functions in your example might have served as a clue. :)

    • Re: (Score:3, Interesting)

      by mini me ( 132455 )
      The thing that makes Ruby stand out above the languages I'm well versed in (unfortunately Python isn't one of them) is its metaprogramming abilities. For lack of a better way to describe it: You don't write Ruby programs. You write Ruby programs that write Ruby programs. If Python is the same in this regard, then I guess probably nothing.

      • You don't write Ruby programs. You write Ruby programs that write Ruby programs.

        I have a Python class that contains a list of functions that must all eval to True before certain actions can take place. If a test failed, I wanted to return an explanation to the user, and decided to store that in the function's docstring. In Python that's an unlinked string at the very beginning of a function definition:

        >>> def foo():
        ... "This doesn't do anything useful"
        ...
        >>> print foo.__doc__
        This doesn't do anything useful

        By the way, Python's self-documenting system uses the

    • 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 towar

    • Re: (Score:2)

      by WNight ( 23683 )
      To actually do any given thing, no.

      To program in for fun, yes. To do things you'd never have thought of doing, yes.

      Blocks and iterators: [1,2,3].collect {|x| x ** 3 }.each {|x| puts x.to_i }

      It's like specifying arguments that contain code. Functions you otherwise would have to pass a ton of arguments to, or provide a call-back function for, take an anonymous block.

      Ruby's a very quick language. You can get something done quickly like Perl, and it has nice shortcuts like "foobar" =~ /Foo/i for regexps, et

    • Re: (Score:2)

      by renoX ( 11677 )
      [[does Ruby have anything to offer for someone who's already very proficient in Python]]

      Not much in my opinion: while I was looking for a language I'd like I found both Python and Ruby and had quite some difficulty to find one that I'd like better than the other one: in fact those language are very similar.

      So as you're already using Python, I doubt that you'd see much benefit going to Ruby.

      Myself finally I chose Ruby, unfortunately I'm doing much more Perl (bleach) than Ruby.. :-(

    • Re:Why Ruby? (Score:5, Interesting)

      by astrashe ( 7452 ) on Wednesday December 26, 2007 @09:50AM (#21821134) Journal
      I don't know Python, and I don't want to try to compare Ruby with it. And I'm not a real programmer, just an amateur, so take this with a big grain of salt. I could be completely wrong here.

      The heart of Ruby is its use of idiom. It's a difficult thing to describe, and I don't know how you'd find some metric to measure it, or to compare it to another language. But it's very clean, and very sensible, and surprisingly simple, at least on the surface.

      There's a kind of aesthetic pleasure to be had in the syntax of Ruby. I was about to write that in that sense it's kind of an anti-perl, but that's flame bait, and I never connected with perl, and lots of people probably find perl beautiful. But Ruby is really great.

      You can do things like:

      1.upto(10) {|x| puts x }

      Which does:

      1
      2
      3 ...

      This thing looks a lot like an old fashioned for/each loop, but it's an iterator, and the code in the curly brackets is a closure. So under the hood, it's fairly different from a for/each loop.

      There are a few things to mention about this.

      First, because there are lots of iterators on the shelf, and because you can write your own iterators if you want, this thing is a lot more powerful than looping constructs in many other languages.

      Second -- and this is the sort of thing I was trying to get at above -- the syntax for closures is tweaked so it makes human intuitive sense when you're using closures with iterators. In your head, you might be thinking in for/each terms, and the syntax colludes with you if you want to hang on to that useful fiction.

      In Lisp, you can never forget about the lambdas. In Ruby, you just sort of do what you want, and the lambdas are there under the hood, but they're not jumping out at you in the same way. Ruby's syntax fits the way a lot of people think, and it hides the stuff that it makes sense to hide, and exposes the stuff that it makes sense to expose.

      And when you write out that line of code, its meaning is very clear and easy to grab a hold of, and it turns out that it's usually very concise and compact as well.

      This is a little redundant, but I want to stress it, that line of code really is a pretty thing, in a sense. It's not so remarkable if you think of it as a for/each loop, but it's not a for/each loop -- it's an iterator and a closure, and that's a somewhat complicated thing, but here it isn't complicated, or opaque. It's clean, and it makes sense, and it's concise, but most of all, the shape of the code conforms to the shape of the idea in your head. That's what Ruby is all about, and you see that over and over and over again.

      Third, this approach to idiom is a real dual edged blade for me, because there's a culture in Ruby books that sort of says, "You know what this line of code is doing, so don't worry too much about the lambdas." For a long time, I felt lost in Ruby -- like, I kind of knew what the code was going to do, but I wasn't exactly sure what was going to happen under the hood. That's a really uncomfortable place to be. I had to watch the SICP lectures to really grab hold of Ruby.

      It's always dangerous to talk about some other culture -- I could be way off base here, and I hope I don't say anything really dumb. But it feels Japanese to me -- it reminds me of a drawing where there aren't many lines, but all the lines are kind of perfect and clean. It's got that same sense of elegance to it. Let's boil this big thing down to its essence, and make it beautiful and sparse.

      I can't tell you that Ruby is better than some other language. But I can tell you that it's very beautiful, and that the beauty lives in lots of small little details. The experience of learning and using Ruby is one of noticing these little things and saying, "Wow, how great is that?"

      I used to live in an apartment building that had been designed by a famous architect -- Mies van der Rohe. The design made a difference -- I can't tell you why or how, exactly, but it d

  • I'd like something else. (Score:3, Insightful)

    by jd ( 1658 ) <imipak@[ ]oo.com ['yah' in gap]> on Tuesday December 25, 2007 @11:45PM (#21819010) Homepage Journal
    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.

    • It's probably not what you're looking for, but Ruby's standard library provides a Linda-like approach to distributed computing. It's works quite well, though it's certainly no Erlang.
    • 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.

      I'm waiting for somebody to write a Ruby to Erlang-bytecode compiler. Heck, even a Parrot compiler would be welcome, so I can write in Ruby and use CPAN. *That* would be something no languages can do now (efficiently, anyway). It wouldn't be for just one language, though, they'd all win.

      • Re: (Score:2, Informative)

        by chromatic ( 9471 )

        There's a Ruby implementation on Parrot called Cardinal. It stalled for a while until the Parrot 0.5.0 release in November, but that should have cleared the next few roadblocks.

  • where's unicode? (Score:3, Interesting)

    by sentientbrendan ( 316150 ) on Wednesday December 26, 2007 @03:15AM (#21819780)
    I can't help but notice that there's nothing mentioned about unicode. I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support. After all, it's not like only English speaking people use rails websites...

    • Re:where's unicode? (Score:4, Informative)

      by Riemann hypothesis ( 1207970 ) on Wednesday December 26, 2007 @04:00AM (#21819912)
      There is support for Unicode in Ruby 1.9. An encoding is now associated to a string and you can also perform transcoding, therefore converting a given string amongst different formats (e.g. UTF-8 and ASCII).

    • Re: (Score:2)

      by JanneM ( 7445 )
      I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support.

      Ruby isn't a web development language. It's been used to write a web development framework, which isn't the same thing. And Japan has not picked up Unicode since it has some rather dumb issues with Japanese (missing characters and the like). You preferentially use other encodings.

    • I can't help but notice that there's nothing mentioned about unicode. I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support.

      Ruby's slow adoption of Unicode is largely because it was developed by a Japanese developer. See, for an overview of the issues, here [jbrowse.com]. And, indeed, that's probably why, while Ruby is gaining more Unicode support, Ruby will probably not be as Unicode-centric as some languages are in the fo

  • It's nice to see that Ruby interpreter speed is improving. Performance and compile time checking (think static types) are about the only areas in which I find Ruby lacking. Looking at the table on the shootout page, though, I find that performance has only improved by a factor 2. That's impressive...but it's not enough.

    Last I measured, Ruby was about a factor 300 slower than C on low-level code (measuring the performance of high-level functionality implemented in the interpreter is not so interesting, becau

    • Re: (Score:2)

      by sohp ( 22984 )

      compile time checking (think static types)


      Perhaps Ruby is not the language for you?

      (Ruby is a dynamic language, static/manifest typing is pretty much 180 degrees opposite the philosophy of the language).

Slashdot Top Deals

The world is not octal despite DEC.

Close