Slashdot Mirror


Ruby 2.0.0 Released

An anonymous reader writes "Today version 2.0.0 of Ruby has been released. This is a stable release, and the Ruby team has done their best to make it compatible with 1.9, making it easier to migrate than it was to switch from 1.8 to 1.9. New core language features include: 'Keyword arguments, which give flexibility to API design; Module#prepend, which is a new way to extend a class; A literal %i, which creates an array of symbols easily; __dir__, which returns the dirname of the file currently being executed; and UTF-8 default encoding, which make many magic comments omissible.' There are also new built-in libraries for lazy stream and for an asynchronous exception handling API. The release includes a number of performance improvements and debug support for DTrace."

121 comments

  1. Yay! by Anonymous Coward · · Score: 1

    But when will it be available in my apt-get?

    1. Re:Yay! by Anonymous Coward · · Score: 0

      If you know how to use Ruby, you should know how to install from source.

    2. Re:Yay! by Anonymous Coward · · Score: 0, Troll

      Yeah, sure, like all the hipsters that use Ruby and MongoDB just to be edgy even know what "compiler" means. Be thankful he knows how to use the CLI.

    3. Re:Yay! by noh8rz10 · · Score: 3, Funny

      where can I get my ruby 2.0.0 slippers?

    4. Re:Yay! by Anonymous Coward · · Score: 3, Informative

      Use RVM:
      rvm get head && rvm install 2.0.0

    5. Re:Yay! by Anonymous Coward · · Score: 0

      Ah, the "real programmer" has spoken.

    6. Re:Yay! by Anonymous Coward · · Score: 1

      Why? Yet Another Fscking Package Manager. I've got a perfectly working apt-get, and until ruby 2.0.0 is in there it doesn't count.

    7. Re:Yay! by Anonymous Coward · · Score: 1

      Until you have 2 apps on different versions that require mutually incompatible libraries due to said version difference.

    8. Re:Yay! by Bill_the_Engineer · · Score: 1

      But when will it be available in my apt-get?

      Ask your debian/ubuntu package maintainer. You could just use RVM or rbenv-build.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    9. Re:Yay! by ls671 · · Score: 1

      $ rvm
      The program 'rvm' is currently not installed. You can install it by typing:
      sudo apt-get install ruby-rvm

      it doesn't seem like a package manager but more like ruby's own tool; Ruby Version Manager

      http://manpages.ubuntu.com/manpages/precise/man1/rvm.1.html

      http://rvm.io/

      --
      Everything I write is lies, read between the lines.
    10. Re:Yay! by Anonymous Coward · · Score: 0

      Who modded this idiot up? It was an obvious troll.

    11. Re:Yay! by rubycodez · · Score: 2

      in Ubuntu or Linux Mint or Debian, get the prerequisites
      sudo apt-get install libyaml-dev ncurses-dev libreadline-dev bison libgdbm-dev libc6-dev libssl-dev libmysql++-dev libsqlite3-dev make build-essential libssl-dev libreadline6-dev zlib1g-dev libyaml-dev gcc

      then download the ruby2 source from ruby-lang.org. then untar it and make/install it:
      tar xvfz ruby-2.0.0-p0.tar.gz
      cd ruby-2.0.0-p0 ./configure
      make
      sudo apt-get install

      see if it works:

      /usr/local/bin/ruby -v
        ruby 2.0.0p0 (2013-02-24) [x86_64-linux]

        /usr/local/bin/ruby -e '2.times { p "ruby is fun!" }'
      "ruby is fun!"
      "ruby is fun!"

    12. Re:Yay! by rubycodez · · Score: 1

      wow, slashdot formatting sure mangled some of that. let's putsome explicit < br / > in there:

      tar xvfz ruby-2.0.0-p0.tar.gz

      cd ruby-2.0.0-p0
      ./configure

      make

      sudo make install

    13. Re:Yay! by Anonymous Coward · · Score: 0

      > Why? Yet Another Fscking Package Manager.

      Because new stuff gets faster to users. The "wait till the monolitic distribution packages it" model is fundamentally broken.

      > I've got a perfectly working apt-get, and until ruby 2.0.0 is in there it doesn't count.

      You're right. Until Ruby 2.0.0 is is there, apt-get doesnt count.

    14. Re:Yay! by tick-tock-atona · · Score: 1

      on debian, there are better alternatives to rvm:

      apt-get install ruby-build
      rbenv install 2.0.0-dev

      In addition, with rbenv, no-one is encouraged to use gemsets instead of bundler.

    15. Re:Yay! by Darth+Snowshoe · · Score: 1

      "Rubyist hipsters down at Starbucks"? Are you joking me? Maybe you just go to a better Starbucks than mine -

  2. NIce by Anonymous Coward · · Score: 0

    I started playing around with ruby about a month ago and so far im very impressed with how simple it is .

      ( somewhat off topic but anyone got any code for a beginner to take a look at ? I've been trying to go thrugh the source but it's proving a bit much for me)

    1. Re:NIce by Anonymous Coward · · Score: 2, Funny

      Your code indentation is wrong.

    2. Re:NIce by Anonymous Coward · · Score: 0

      That's Ruby, not Python.

  3. Re:I'm sure... by Anonymous Coward · · Score: 0

    I think its funny that you poo-poo Ruby, but mention the next hipster language in line -- Python.. Welcome to the echo-chamber :)

  4. Re:I'm sure... by Anonymous Coward · · Score: 0

    In the meantime, the rest of the world is using "big boy languages" that people give a damn about like JAVA and C# and Python.

    Those "big boy language" cower before the awesome power of TREE-META.

  5. Re:I'm sure... by Anonymous Coward · · Score: 0

    Glad you didn't list PHP

  6. I WANT RAILS ON MY RUBY !! by Anonymous Coward · · Score: 0

    How come I get no rails ?? I want RAILS !! I need to stay on the track !! I do !!

  7. Too early! by Anonymous Coward · · Score: 5, Funny

    Should have been released on Tuesday. Ruby Twosday. :D

    1. Re:Too early! by Anonymous Coward · · Score: 0

      Should have been released on Tuesday. Ruby Twosday. :D

      Twosday?:
      Who could hang a name on you?

  8. Re:I'm sure... by Anonymous Coward · · Score: 0

    Yes, the uber secure Java, LOL

  9. Review Ruby for the perl enthusiast please by goombah99 · · Score: 1, Interesting

    Could someone offer a comparison of ruby to perl in terms of replacing perl as a command line quickie or short admin or text processing. I use python for writing serious programs. But for getting quick things done like say shredding some text copied off a telephone directory web page to pull out a list of telphone numbers and peoples names, or parsing the text output of some unix right on the command line, perl is the right tool, python is not. If you don't know that that is true then you are not an experienced perl person.

    But I've looked at ruby syntax a bit and it looks like it might have the advantage perl has for quick ad hoc text parsing but an overall cleaner syntax.

    What I don't care a lot about is fancy pants modules like rails. If I want to do something serious there's python.

    two things I like about perl: perl is lightning fast to start from the command line so glue scripts between applications like blast and something else dont' slow things down, and the O'reily nut shell book is the thinest book (even thinner than C++) yet it's a very poerful language. (yes I have looked a Lua)

    please respond with a review of ruby for a perl enthusiast.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 2, Insightful

      Your message is basically a trap. In order to answer, one has to accept the implied assertion that "Ruby is not something serious".

      If you enjoy Perl, keep using it, man. Lots of ex-perlists are now doing ruby. Ask them why. You might want to control your tone though; ruby is what puts food on their children's table. You might not want to call it "not serious" on their face.

    2. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      So, you want someone to spend their time writing something to try and convince you of something? If you're such an "experienced perl person", why not do the research yourself and post it here? You know the kinds of tasks that you typically use perl for - take one or two of them and convert them to ruby and see the results yourself.

      Not only that, but it sounds like you've already pre-judged ruby by putting in the same category as perl for you i.e. a language for "non-serious programs".

      TL;DR: do it yourself, lazy-ass

    3. Re:Review Ruby for the perl enthusiast please by reSonans · · Score: 5, Funny

      the O'reily nut shell book is the thinest book (even thinner than C++)

      You're right, O'Reilly's C++ In a Nutshell is a mere 810 pages long, whereas their Perl in a Nutshell, 2nd Edition is a scant 768 pages.

      When I think C++ and Perl, I think lean.

      --
      Light the blue touch-paper and retire immediately.
    4. Re:Review Ruby for the perl enthusiast please by bauerbob · · Score: 1

      Ruby is not a good replacement for Perl in means of one-liner or shredding text files. Its clean OO implementation forces you to write a lot more code. But Ruby is a good alternative for Python. It's for - like you say - doing serious stuff.

    5. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      You might not want to call it "not serious" on their face.

      Or what, they're going to nerd rage all over you?

      ROR is still a toy, and that's the lion's share of the Ruby deployments.

    6. Re:Review Ruby for the perl enthusiast please by Serious+Callers+Only · · Score: 4, Insightful

      1. Ruby is not a toy not suitable for 'serious' programs, it's very similar to Python in fact, it's not as strong on science or math though as python because of libraries available in Python, if that's what you mean, say that, it's far more convincing.
      2. Python could easily replace Perl for system admin tasks - come up with specific criticisms if you have met with any roadblocks - you would likely find similar problems with Ruby to Python if you somehow couldn't manage sysadmin or text scripting with Python.
      3. Ruby, Python and Perl are actually quite interchangeable and could all be used for 'serious' tasks, or for short admin or text processing - all 3 are ideally suited to these things, and frankly the differences are not huge, Perl is slightly gnarlier, Python slightly stricter, Ruby slightly more anarchic, all 3 would get the job done easily.
      4. WTF has Rails got to do with any of this? Troll much?
      5. Why should we waste our time trying to convince someone with such trenchant and at the same time wildly inaccurate preconceived ideas?

    7. Re:Review Ruby for the perl enthusiast please by Serious+Callers+Only · · Score: 1

      That's not really true, you can easily write code without OO setup in ruby, in fact you could write code without defining functions if you wish for one liners. e.g. here's a little one liner to count the words in a file.

      ruby -ane 'w = (w || 0) + $F.size; END { p w }' test.txt

      It can be used very like perl if you wish.

    8. Re:Review Ruby for the perl enthusiast please by kwerle · · Score: 4, Informative

      (sorry if this is double-posted - slashdot is choking)

      Perl is way faster. Like twice as fast. Check out my test:
      % time (echo | ruby)
      ( echo | ruby; ) 0.01s user 0.00s system 91% cpu 0.016 total
      % time (echo | perl)
      ( echo | perl; ) 0.00s user 0.00s system 84% cpu 0.007 total

      Though this is ruby 1.9.3. I don't think 2.0 is twice as fast as 1.9.3.

      But I've looked at ruby syntax a bit and it looks like it might have the advantage perl has for quick ad hoc text parsing but an overall cleaner syntax.

      What I don't care a lot about is fancy pants modules like rails. If I want to do something serious there's python.

      If you're happy shredding text with perl, I see no reason to change. If you're happy doing serious work with python, I see no reason to change.

      Ruby is a, dynamic, duck-type OO language with closures, exceptions, and a debugger.
      It has nice library infrastructure: http://rubygems.org/
      It is generally a little less popular than Python and Perl, depending on your yardstick: http://www.langpop.com/

      There are a few implementations of ruby, including one in java (with great bridging to java classes), one for iOS (with great bridging to iOS libraries), and one based on .net (with great bindings there). So if you have a particular target platform, one of those may interest you.

      But here's the cononical answer to your question:
      http://c2.com/cgi/wiki?PythonVsRuby

      You might be interested in JRuby and Jython and their ability to communicate...

      I code in Ruby for a living (Rails), and I think it's a really fun language. Which is something a fair number of rubyists say, and which is something you don't hear a lot of other folks say about their language of choice. For what that's worth...

    9. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      You espouse performance as a benefit of Perl (maybe it is, I have no clue) and then talk about using Python for "something serious."

      I love Python, but I'm under no disillusion about how slow it is. It's also imo horrible for large-scale and medium-scale development because its tools to manage complexity aren't very good for larger projects. Most of this stems from its type system. In my experience, you have to keep all parts of the system in your head even if it's designed well. For some reason, I always end up spending more time in debugging than in programming with Python. This could be because I suck, this could be because I'm more used to static checking, this could be because I don't use much of an IDE for Python (and there aren't very many compelling options...), I don't know.

      In any case, compared with Python, Ruby is much faster now (they used to be roughly equal until the Ruby team put effort into optimizations). I don't know very much else about Ruby, but I've been interested in picking it up for a while. Despite the overbearing hipster smug, it seems pretty worthwhile. Give it a shot. Learning something new can't hurt, if nothing else.

    10. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      PHP deployments = ROR deployments * 10^4

    11. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      Or what, they're going to nerd rage all over you?

      No, they will just ignore you, especially those with the most experience and best chance of giving insightful answers to such questions. Instead, the only replies you get are inarticular crap like this from people who have more interest in stupid arguements that won't go anywhere as opposed to any actual discussion or insight into programming langues. And just telling someone it is a toy does not count as insightful...

    12. Re:Review Ruby for the perl enthusiast please by mortonda · · Score: 4, Interesting

      I code in Ruby for a living (Rails), and I think it's a really fun language. Which is something a fair number of rubyists say, and which is something you don't hear a lot of other folks say about their language of choice. For what that's worth...

      This. So much this.

      Over the years I've used various languages to some degree... C, C++,Java, PHP, Perl.... and Ruby is simply the most fun and most expressive. I'll allow that all these languages have their strengths. (ok, not PHP). Python, too has many valid proponents and use cases, but I just can't have fun in a whitespace sensitive language. Java - I think is nice for people that like to type a lot. The modern day COBOL. But if IIRC, the fastest ruby interpreter is currently JRuby, so I can't entirely fault Java. C and C++ is obviously best for kernels and libraries where speed matters a lot, but obviously horrible for web application development.

      For my own interests in web application development, Ruby on Rails is a sweet spot... I can make a lot of money doing something really fun. What's not to like about that?

    13. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      >> You might not want to call it "not serious" on their face.
      > Or what, they're going to nerd rage all over you?

      It's called "being polite".

    14. Re:Review Ruby for the perl enthusiast please by Serious+Callers+Only · · Score: 2, Informative

      Apart from the maths libraries, multithreading, UTF support (only just in - enjoy the bugs!) cross platform GUIs (TK or Fox. WTF if Fox?)
      Yep, half the speed of perl and a web toolkit more obscure than PHP.

      Ruby has maths libraries (but not as extensive as Python here IMHO), threading, has had Unicode and UTF support for years (since 1.9), and has good support for the best scripting language UI if you ask me (HTML displayed in a browser with the built in web server). I suppose if your idea of 'serious programs' is desktop apps using the platform GUI through some glue code, then you're out of luck (frankly I wouldn't use Perl OR Python for that either, just use C, C++ and/or the platform language of choice). That's a silly definition of 'serious' though.

      Re the speed and web toolkit, you clearly don't know what you're talking about there, plenty of options on Ruby, none of them obscure or difficult, and speed is pretty good nowadays, certainly good enough for almost all applications save extensive number crunching, it's really not a problem in the real world.

      Pick your tools to suit the particular thing you're building (i.e. don't pick a scripting language to build a desktop app), but why limit yourself with silly misconceptions about tech? It's only a scripting language, comparable to many others and suitable for most of the same sort of problems.

    15. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      So that means I make a six figure income playing toys. Man, I must live in heaven!

    16. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      ruby -ane 'w = (w || 0) + $F.size; END { p w }' test.txt

      Kids these days with their fancy pants crap.

      wc -w test.txt

    17. Re:Review Ruby for the perl enthusiast please by dkf · · Score: 1

      Python could easily replace Perl for system admin tasks

      Probably not. Python's not king of the one-line trick in the same way that Perl is, and probably can never become so because of its reliance on the use of whitespace to indicate program structure. Not that I'm complaining about the use of whitespace; just pointing out that it makes things impractical for muscling in on Perl's core territory.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    18. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      It can be used like Perl, yes, but Perl has simple data types, not anything and everything is represented as an object. This adds a tremendous amount of overhead, both in memory and CPU usage, it's one of the reasons why Twitter moved away from Ruby to Java for their future site development. "Everything is an object" is certainly a feature I love as a developer! It just doesn't translate well to things that have to scale.

    19. Re:Review Ruby for the perl enthusiast please by dkf · · Score: 1

      Java - I think is nice for people that like to type a lot. The modern day COBOL.

      The only way Java even gets close to fun is with an IDE so that you don't need to type everything out in full by hand. No, the big advantage of Java is the assload of third-party libraries for doing interesting stuff. ("The modern day COBOL" is spot-on.)

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    20. Re:Review Ruby for the perl enthusiast please by Concern · · Score: 3, Insightful

      Or just don't worry about flattering the ego of people so insecure and unskilled that they require you to pretend that Ruby is a widely used, mature, stable language.

      You want the advice of someone who learns languages effortlessly, and therefore has no insecurity about anyone else's preferences or prejudices. Anyone who needs you to "control your tone" about a language "because it puts food on their children's table" - I fear for those children. And for anyone who gets advice from their parents, who apparently had to struggle a bit too much to pull themselves up to that competency and, fearing criticism of their precious, hard-won skill, give the impression of hanging on by their fingernails.

      Ruby is indeed still at risk of being described as a toy language, and it is not nearly as commonly used as, say Perl, Python, Visual Basic, or even C#, let alone Objective C, C/C++ or Java, (as evidenced here) ...and the community is similarly small. Witness the hilarity around the recent Rubygems compromise to see the price of small size and lack of maturity. The language is still young, and messily and poorly specified, relying on a horrifyingly slow, rats-nest reference implementation for its definition, rather than a comprehensive design.

      There is great cleverness in Ruby. It represents a ruthless preference for developer productivity over performance. An interesting experiment, but unfortunately it was done "by feel" rather than with any hard data about speed or defect rates given different design decisions. So, while some things about it are wonderful, other things only appear to be wonderful. On the whole you are unlikely to experience much net gain over Perl or Python, though you may enjoy the novelty of it. It's a fun language. By all means, try, and see for yourself. Just beware that you foreclose the ability to scale your work easily if you use Ruby.

      Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told), many language features cause meaningful and irretrievable performance impacts that will never be ameliorated by runtime magic. It doesn't matter for many applications, but just something to keep in mind.

      --
      Tired of Political Trolls? Opt Out!
    21. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      > % time (echo | ruby)
      > ( echo | ruby; ) 0.01s user 0.00s system 91% cpu 0.016 total
      > % time (echo | perl)
      > ( echo | perl; ) 0.00s user 0.00s system 84% cpu 0.007 total

      This must be the single lamest benchmark I've ever seen. Please never write any kind of performance-sensitive code again.

    22. Re:Review Ruby for the perl enthusiast please by dkf · · Score: 0

      PHP deployments = ROR deployments * 10^4

      Ah, the "goodness == popularity" argument. Argumentum ad populum is a logical fallacy, you know...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    23. Re:Review Ruby for the perl enthusiast please by siride · · Score: 0

      Java also sports the "everything is an object" mentality. If you were going to make a point about that model, you should have picked a better example.

      And anyway, in Perl everything is still an object. Do you think the variables are actually stored like they are in C? No, they have scope and reference counting info. They are objects. Don't talk about performance and Perl in the same sentence.

    24. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      I won't use ruby for the sheer fact that in order to code ruby you have to be a smug self righteous hipster ass who just barely was talked out of getting a "degree" at Devry..

      You've nailed the smug self righteous hipster ass part. Couldn't get into Devry?

    25. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      He actually was benchmarking how quickly he could get moderated up by posting trivial unix command output.

    26. Re:Review Ruby for the perl enthusiast please by shutdown+-p+now · · Score: 1

      "Everything is an object" is purely about semantics, it does not define how those objects are represented, and does not have to "Add a tremendous amout of overhead".

      I don't know the specifics about Ruby, but e.g. int in C# is an object (a value-type instance, to be specific), with methods etc - and its representation is exactly the same as int32_t in C. Dynamically typed languages have historically used tagged references to achieve similar performance (i.e. when the object reference has a bit that distinguishes between it being a pointer or a regular int).

    27. Re:Review Ruby for the perl enthusiast please by shutdown+-p+now · · Score: 2

      Python way is not too keen on conciseness to the point of unreadability - so it's not good for Perl-style one-liners. Ruby, on the other hand, retains a lot of Perlisms (like $_ etc) solely for that purpose.

    28. Re:Review Ruby for the perl enthusiast please by Frequency+Domain · · Score: 4, Informative

      Java also sports the "everything is an object" mentality.

      Say what?!?!?! Java explicitly distinguishes between primitives and objects! You can't send messages to primitives or literals in Java, only to objects and classes. Contrast with Ruby, where "5.times {p rand}" is a perfectly legitimate way to print five random numbers because the literal "5" is an Integer object which can respond to any message Integers implement.

    29. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      Everything is not an object in Java. It has primitives. Methods/functions are not first class. In Ruby, almost everything is an object, but not quite. Methods/functions have to be turned into procs/lambdas. A function defined in the global main space is not an object and can't be passed around like you do with JavaScript (although you can pass the symbol for that function around and call send on main). SmallTalk and Self are the standard bearers for pure OO.

    30. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      ROR is still a toy, and that's the lion's share of the Ruby deployments.

      At its height Twitter's Rails stack was serving 170,000 requests per second with three nines success rate.

      RoR might be a toy in your hands.

    31. Re:Review Ruby for the perl enthusiast please by Bill_the_Engineer · · Score: 1

      I use Perl and Ruby extensively. The comparisons are: Ruby is slightly faster than perl; It is easier to make C bindings in Ruby; Ruby's object oriented features doesn't involve Moose (Moose isn't necessary, in perl you can still use hash/dictionary type and bless into an object but still is a kludge); Ruby's library packaging system is an improvement over cpan (you can uninstall as easily as you installed); and unlike Perl with Ruby you will never have to debug or maintain code from a colleague who thought TIE was cool.

      Unlike the other two popular interpreted languages, Ruby's upgrade path doesn't necessarily involve giving up code that was developed with a previous version. In Perl's case, Perl 6 may not actually be used in production code in our lifetime if ever.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    32. Re:Review Ruby for the perl enthusiast please by siride · · Score: 0

      And every primitive has a class version, to which the primitives are automatically boxed when they need to be treated like objects. There are only a few places where the distinction matters at all (arguments by value being the chief of these).

    33. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 1

      I like to point out that you can use GTK with Ruby and for OS X you have MacRuby and iOS you have RubyMotion.

    34. Re:Review Ruby for the perl enthusiast please by Serious+Callers+Only · · Score: 1

      : )

    35. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      So, can you send a message to a literal in Java?

    36. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      You say that as if it's a bad thing.

      I don't get why Slashdot seems to insist on either shoehorning everything into a particular language or lambasting it for lacking the ability to do just that... Every tool has its proper use. Java too, has its proper use, and as much as Oracle gets panned for security lately I think the followup and the number of patches within the month that followed that fiasco would at _LEAST_ suggest they take it seriously.

      If I were doing something that I wanted to (hopefully :P) run from one compiled binary on all supported platforms (roughly) the same way, I'd use Java.....if I wanted to do serious scripting or scientific work I'd use Python, if only because of NumPy and SciPy as others have suggested. If I was just doing some system scripting or "glue" coding? Sure, I'd use Ruby. It's simple, flexible, easy to understand, doesn't take a long time to learn...all of which are good things for the person writing the code as well as the person maintaining it. But I wouldn't try to do what I could in Ruby in Java, it'd take too long. Likewise I wouldn't write the same application in Java that I would in Ruby, because there's too much messing around for the end user -- install a ruby interpreter on x given platform, install whatever gui I decide to use (probably qt4 or tk as a fallback), keep all of those up to date manually if you're using windows... It's all a lot of trouble if you can get more or less everyone to type java -jar whatever.jar and have it run (again roughly) the same on every platform. I haven't found anything yet that replaces java for that particular use, that's supported across so many platforms, but I'd certainly be willing to learn!

      TL;DR - ignore the flamewars, pick what best suits your needs. There are multiple languages for a reason, not all of them are good at the same thing and _none_ of them are good at everything.

    37. Re:Review Ruby for the perl enthusiast please by Serious+Callers+Only · · Score: 3, Informative

      Perl's speed is pretty similar to Ruby, it's nowhere near the Java VM nowadays, plus Ruby is available on the JVM if that's what you prefer to use. But the parent was talking about system admin scripts and little one liners run on the command line. If you're expecting them to be 'webscale' you're talking about something else entirely. I don't know about you but my system admin scripts are not expected to scale past the few machines I work on and run by precisely one user at a time, they're not user-facing scripts and therefore performance is not critical - they could be in any language really, I don't really use one-liners but it is quite possible to do them in all those languages, even Python.

      Finally, re Twitter, if you try to reinvent a messaging server using a CRUD web app (a la twitter), you can expect all kinds of pain, even if you write it in enterprise ready Java in the first place. I imagine their problems were more down to entirely the wrong architecture, though now that they are one of the biggest sites on the internet, things like language choice will become very important for them. It's interesting though that a site like Facebook compiles PHP to C++ and then to one big binary in order to stay up and still use one of the slowest languages available - if they wished twitter could easily have done something simliar with Ruby or moved to using the ruby on the JVM, but the new people brought in to make it work were probably coming from Java backgrounds and as it need a rewrite, they thought why not, and why not indeed, it's worked out pretty well for them. They were still on Ruby 1.8.7 till the end I think, which was pretty insane given the improvements in Ruby 1.9 and points to serious problems with the older code.

    38. Re:Review Ruby for the perl enthusiast please by Bill_the_Engineer · · Score: 2, Insightful

      Perl is way faster. Like twice as fast. Check out my test:
      % time (echo | ruby)
      ( echo | ruby; ) 0.01s user 0.00s system 91% cpu 0.016 total
      % time (echo | perl)
      ( echo | perl; ) 0.00s user 0.00s system 84% cpu 0.007 total

      So if I tolerate an additional 9 ms of startup time, I could write slightly faster interpreted code in a language with enough syntactic sugar to make mixing OO code with functional code less painful? Cool. ;)

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    39. Re:Review Ruby for the perl enthusiast please by Frequency+Domain · · Score: 2

      And every primitive has a class version...

      Which emphasizes the point - they are different things, or the duplication wouldn't be necessary.

      ...to which the primitives are automatically boxed when they need to be treated like objects.

      Auto-boxing/unboxing is an unbelievably ugly kludge which exists specifically because Java distinguishes between primitives and objects. After enough programmers kvetched about the ugliness and extra code that was needed, Sun threw auto-boxing in somewhere around Java 1.4 or 1.5.

      Languages with a true "everything is an object" model don't need such an awful hack. They also don't require umpteen implementations of containers or sorting (one for Objects and one apiece for each of the primitive types), with all the library bloat that entails. They don't need the programmer to be mentally tracking which elements are primitives and which are objects, and making sure to use the right constructs for each.

    40. Re:Review Ruby for the perl enthusiast please by ls671 · · Score: 1

      add shell scripting and it is all you need for "shredding text files" really.

      --
      Everything I write is lies, read between the lines.
    41. Re:Review Ruby for the perl enthusiast please by Greyfox · · Score: 1
      I inherited a fairly large Ruby application from someone else, and I don't find it fun at all. It's not fun because the original author didn't write unit tests, so any change made to the application can potentially have errors not caught prior to deploy. For development on any scale past trivial, your developers really need the discipline to code unit tests for everything. This is not something developers are known for.

      This application is also not particularly well designed. This is not a problem specific to Ruby, of course. But it does prove one other point; just because you're writing your code in Ruby doesn't mean you crap daisies and unicorns. And just because you're using Ruby for your project doesn't mean you can hire chimpanzees to write your program for you. A steaming pile of crap code looks the same, no matter what language you're using.

      In this particular case, I need to clean up the design to the point where I can write unit tests for it. But if I'm going to do that, I may as well rewrite the code in C++ while I'm at it. What we're trying to do isn't well suited to a scripting language to begin with -- there's a lot of numerical processing going on in the code, and it's pathetically slow in Ruby. So I can just write the bits in C++ as I go and write unit tests for my C++ classes instead. The C++ compiler will catch a lot of the spelling errors that Ruby would not have, but I still want to insure that my classes function correctly when future changes are made to them.

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    42. Re:Review Ruby for the perl enthusiast please by drinkypoo · · Score: 2

      Python's not king of the one-line trick in the same way that Perl is

      I know a lot of people one-line perl, but I never do. Every perl script I've ever written has been commented and readable and basically looked a lot like C without the torture. But I still have little interest in learning python and none in learning ruby, and what interest I have is based solely upon popularity.

      Point is, that's not why python didn't get traction.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    43. Re:Review Ruby for the perl enthusiast please by kwerle · · Score: 1

      I'm sorry you got handed a poorly written project.

      If you do a lot of number crunching, you might want to check out JRuby. Porting is often trivial, and number crunching (or adding pure java functionality) may speed things up a lot.

      But the first thing I'd do is write a bunch of unit (and integration) tests so that you know where you stand.

      Good luck!

    44. Re:Review Ruby for the perl enthusiast please by Bill_the_Engineer · · Score: 1

      1. Ruby is not a toy not suitable for 'serious' programs,

      This double negative tripped me up a little. Once I put my glasses on I understood you meant to say "Ruby is not a toy. It is as suitable for 'serious' programmers as Python". ;)

      Anyway I really want to reply to this:

      ... frankly the differences are not huge, Perl is slightly gnarlier, Python slightly stricter, Ruby slightly more anarchic ...

      Perl is the "strictest". I love "use strict" (more accurately: use strict "vars") and wish that Python and Ruby had something similar to it. Sure you can't use a variable until it is assigned a value, but why not have the ability to catch assignments to misspelled variables during the compile phase?

      Also Ruby shares its anarchic roots with Perl since TIMTOWTDI (There is more than one way to do it).

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    45. Re:Review Ruby for the perl enthusiast please by Greyfox · · Score: 1
      Yeah, to write unit tests the design has to improve. Someone basically used objects as places to hold random, often unrelated functions. There aren't discrete enough areas of functionality that you can just test any one thing. The whole thing is very tightly coupled, too. So I need to segregate the areas of functionality and make real objects that hold real data and have real lifetimes. Ideally the whole thing could be broken up into several libraries that all provide useful functionality on their own. Then I'll be in a position to write and have unit tests.

      But like I said, if I'm going to go to all that trouble, I may as well just write it in a language that's suitable for scientific processing. C++ is really made to do this sort of thing. C++ also doesn't change language syntax every other minor release. Another thing that's coming up is Ruby 1.8.7 going out of its support cycle. So if I stick with Ruby, I'm going to have to make sure that all the code still works correctly in 1.9 or 2.0. I have enough bit rot happening with this application that I really don't need any more from the language itself.

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    46. Re:Review Ruby for the perl enthusiast please by kwerle · · Score: 1

      Yeah, sounds like the project is a rewrite.

      As for syntax changes, I think that 1.8 is forward compatible to 1.9 (though strings became UTF compliant?), so maybe some edges in there. Last time I tried my 1.9 app in 2.0.alpha/beta/whatever, it just worked. In general the language has been very forward compatible and the revs have only happened every few years. Rails has a history of slapping developers around for major releases, but for the progress they're making and with the historical support, I don't mind at all.

    47. Re:Review Ruby for the perl enthusiast please by miroku000 · · Score: 1

      And every primitive has a class version, to which the primitives are automatically boxed when they need to be treated like objects. There are only a few places where the distinction matters at all (arguments by value being the chief of these).

      That's not true at all. you can't say 'a'.toLowerCase() in Java. You have to do something like Character('a').toLowerCase(). That's not transparent at all. And God forbid you want to add methods to the Integer class in java.

    48. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      You sir, are a troll.

      github.com is arguably the best thing to happen to open source in recent years. According to github, it is the second most popular language on their site. That said, I don't believe popularity is a great justification to use to pick a language to develop in.

      There is economic merit in choosing developer productivity over performance. Most of the time, small changes to the speed of execution of a program don't matter. Hardware is a lot cheaper than a programmers time.

      I'm not sure where you got the idea that ruby doesn't scale from, but I'd be interested to see what language decisions you think make this so. The GIL (GVL)? If you think scaling can only be done with threads, I'd like to show you node.js. Or apache. Or any evented or fork based server infrastructure.

      I'm all for pointing out the weaknesses of a language, but you're making really large statements without even examples to back them up. It's FUD, plain and simple.

    49. Re:Review Ruby for the perl enthusiast please by pipy · · Score: 1

      For some reason, I always end up spending more time in debugging than in programming with Python. This could be because I don't use much of an IDE for Python (and there aren't very many compelling options...)

      You are doing it wrong. There is a first-class IDE for Python (I mean, really first-class, by all standards), PyCharm. Give it a try and see the your productivity go way up.

    50. Re:Review Ruby for the perl enthusiast please by serviscope_minor · · Score: 1

      Languages with a true "everything is an object" model don't need such an awful hack. They also don't require umpteen implementations of containers or sorting (one for Objects and one apiece for each of the primitive types), with all the library bloat that entails.

      That's also a feature of languages with proper generics support: you don't need everything to be an object to have single implementations of containers.

      --
      SJW n. One who posts facts.
    51. Re:Review Ruby for the perl enthusiast please by siride · · Score: 1

      Fair enough. Java still otherwise wants to follow the everything is an object model. The primitives do stick out like a sore thumb, you are right. Thankfully, .NET fixed this problem.

    52. Re:Review Ruby for the perl enthusiast please by Concern · · Score: 2

      I cited a comprehensive survey. You just talked about github. Yes, a particular open-source repository (Github) is popular among Ruby developers. The fact that you confuse this with language popularity is another hint about your critical thinking skills.

      There is indeed economic merit in choosing developer productivity over runtime performance. However, there is no need to choose one or the other. Many other languages exist that are fine competitors to Ruby in terms of developer productivity, and most will not run as slowly. If you ignore them, your career will suffer.

      I have invested many years in Ruby at this point, and I hope you can see that I am not unaware of its benefits. This is how I came to be in the position to scale Ruby applications, though of course, rather than have the droll exercise of being blindly accused of being "bad at it," I will refer you to the innumerable published experiences of famous Ruby developers who had to abandon the language due to scale issues. For theory, I will refer you to the excellent work of Charles Nutter, author of JRuby, currently among the best performing Ruby VMs, and far beyond Matz's work.

      I have backed up every statement I've made, though if you feel that having a global interpreter lock is some kind of virtue, and does not reduce the scalability case of your language, you are stating something so extraordinary and beyond the pale of any conventional wisdom or common sense, it is upon you to prove it - to the astonishment of all, I assure you.

      If you are getting by with forks and multi-tiered archtectures and high-open file limits and Passenger, I salute you. But if you really are this insecure and uninformed about Ruby, I suggest you learn another language - Groovy perhaps, or Python - or push yourself and learn Objective C or C++. Alternately, consider work on addressing the flaws in Ruby - your help is certainly needed, and you might give your beloved platform better hope for the future.

      --
      Tired of Political Trolls? Opt Out!
    53. Re:Review Ruby for the perl enthusiast please by Frequency+Domain · · Score: 1

      Java still otherwise wants to follow the everything is an object model.

      I don't think that means what you think it means.

      The primitives do stick out like a sore thumb, you are right.

      Who'da thunk this was such a hard concept? Look, if there are primitives in a language, then pretty much by definition not everything is an object.

    54. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      Languages with a true "everything is an object" model don't need such an awful hack. They also don't require umpteen implementations of containers or sorting (one for Objects and one apiece for each of the primitive types), with all the library bloat that entails.

      That's also a feature of languages with proper generics support: you don't need everything to be an object to have single implementations of containers.

      Go study some formal logic. A => B is not a statement that B => A, nor does it rule out C => B. Your "contribution" is a non-sequitur.

    55. Re:Review Ruby for the perl enthusiast please by Wdomburg · · Score: 1

      It's hard to gauge exact numbers, but pointing to Ruby on Rails as the whole of the Ruby ecosystems is a bit of a chestnut these days. Ruby is become an increasingly important systems language. See, for example - vagrant, chef, puppet, mcollective, capistrano, aeolus, logstash, beanstalk, facter, buildr, etc etc.

      Even within the realm of web applications, Rails isn't the only game in town. Sinatra has rocketed in popularity, inspiring inspiring similar micro-frameworks in a dozen other languages (see: dancer, flask). And there are a number of other smaller frameworks (like Grape, which is specifically for building RESTful APIs).

    56. Re:Review Ruby for the perl enthusiast please by metamatic · · Score: 1

      I switched to Ruby from Perl back when Perl 6 was in the early stages of development. I haven't regretted it at all. There are more Ruby Gems than CPAN packages now, the regexps are just as good, and the language syntax is so much cleaner.

      Back on Ruby 1.8, Perl was about twice as fast, but these days Ruby has improved a lot, and there are also options like JRuby and Rubinius.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    57. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      I work for a fortune 50 (not a typo) company. I program in ruby because our configuration management tools that we chose is written in ruby. I wouldnt consider myself hip, more old school nerd, and I can say that I dont have a degree from Devry or any college. I am a high school drop out.

      Your argument is invalid

    58. Re:Review Ruby for the perl enthusiast please by Anonymous Coward · · Score: 0

      I love how you villify Ruby's global interpreter lock (GIL) as a serious performance issue and then go on the recommend that the reader use a better language -- Python -- which itself has a GIL with exactly the same limitations.

      Bad for Ruby but fine for Python eh? You are quite the objective one now aren't you?

    59. Re:Review Ruby for the perl enthusiast please by Concern · · Score: 1

      Let's see. What did I say?

      Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told)...

      In other words, Ruby's scalability concerns come from a designer with so little care for performance as to sell the GIL as a virtue - scarcely any smarter than this Anonymous Coward. :) By now others have written superior Ruby interpreters, in part because of how bad Matz's is. To this exact point, I linked to a blog post, by the author of JRuby, a Ruby environment which incidentally has no GIL, discussing many serious performance challenges which can never be easily addressed, because they are tied to fundamental language design decisions.

      The reason we are still discussing the GIL at all - a solved problem for both Python and Ruby if you are willing to switch runtimes from the "default" - is that initially we heard "If you think scaling can only be done with threads..." - which... just listen to yourself, man.

      Do I make any specific recommendation the reader use Python? Not only not, but I am actually not even suggesting avoiding Ruby - merely saying, check it out for yourself, and see it not as some mediocre hack's jealously guarded fetish, but objectively, in the context of other languages. I think "you are unlikely to experience much net gain" vs. Perl or Python, but YMMV. On some projects you actually know scale will never be an issue.

      Seen objectively, Ruby has many interesting features, but many are present in other languages. It has some serious problems, some of which are tied inherently to these very features (and therefore cut across languages), but others which are unique to Ruby. Python's problems are a whole separate conversation - not just its own distinct performance issues (at least attacked more vigorously, for longer, and by a larger community), but getting bitten by tabs vs. spaces? :)

      Alas, the AC will have to work a bit harder to know his tools and follow the conversation. :)

      --
      Tired of Political Trolls? Opt Out!
    60. Re:Review Ruby for the perl enthusiast please by jbolden · · Score: 1

      That's interesting. I've almost always heard the opposite that Perl is faster than Ruby. Though looking at the recent results that is no longer true.

      As for Perl 6, I agree that's been a badly badly mishandled project.

    61. Re:Review Ruby for the perl enthusiast please by DragonWriter · · Score: 1

      Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told)

      You probably shouldn't treat gossip as reliable. The Ruby GVL (the Ruby equivalent of the Python GIL) is an artifact of the conversion to the native-threading YARV VM (originally, one of the alternative runtimes) from the old original green-threaded implementation, Matz has never (at least that I've seen, and it would be out of line with a lot of what I have seen him say) described it as a "virtue". YARV was just the most-alround-ready-for-mainstream-use native-threaded alternative runtime, and was chosen because better-than-what-we-have now is better than perfect-sometime-later. There's already quite a bit of talk in the community about moving the mainline to Rubinius once it is ready-enough to be the mainstream.

      The gossip you heard might have evolved from something Matz has actually said, which is that *given* the rest of the current mainline implementation, replacing the GVL with fine-grained locks (which has been *done* by the mainline maintainer, though not released) proved to degrade performance of single-threaded code in a way which would negatively impact lots of current users. This isn't saying the GVL is a virtue, its saying that the current efforts to replace it in the context of the current mainline implementation have proven to not meet Matz's gain-for-pain tradeoff preferences.

    62. Re:Review Ruby for the perl enthusiast please by Concern · · Score: 1

      Could be.

      I did heard it directly from a pretty credible source, someone famous in the Ruby community that I will not embarrass by drawing into this thread, so feel free to say, from no one. Is it written anywhere? I haven't found it in 30 seconds, so I give up. :) What I did find was implication:

      http://merbist.com/2011/10/03/about-concurrency-and-the-gil/
      http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads

      "Data safety" - meaning, Ruby is not a threading language, threading is hard, leave it to something else to do something that hard, while Ruby stays "safe" and "easy." In other words, we have a GIL because it's good to have a GIL. Which tells you all you need to know about what it will be like to scale a language written by this person. Then of course there's all the discussions about how hard it would be to remove - and removing it without a rewrite is certainly hard, I am sure.

      --
      Tired of Political Trolls? Opt Out!
    63. Re:Review Ruby for the perl enthusiast please by DragonWriter · · Score: 1

      I did heard it directly from a pretty credible source, someone famous in the Ruby community that I will not embarrass by drawing into this thread, so feel free to say, from no one. Is it written anywhere?

      The particular comment regarding the effect of removing the GVL that I refer is directly attributed to Matz at Rubyconf here, but isn't a direct quote.

      "Data safety" - meaning, Ruby is not a threading language, threading is hard, leave it to something else to do something that hard, while Ruby stays "safe" and "easy."

      No, that's not what "data safety" means. "Data safety" has nothing to do with "easy".

      Data safety is, in fact, the reason you have to locking of some kind, whether fine grained or GVL -- if data safety wasn't a concern, it wouldn't be an issue. So, yeah, that's obviously the fundamental reason. But the reason for keeping the GVL rather than fine-grained locking with the current mainline implementation -- since the GVL, per the above link, was removed from the mainline implementation and resulted in performance degradation for single-threaded tasks -- appears to be about unacceptable costs, not about what is easier (since the work was, in fact, already done, it would be just as easy to use it as not.)

      Then of course there's all the discussions about how hard it would be to remove - and removing it without a rewrite is certainly hard, I am sure.

      It probably would be, just as it would have been hard to switch from green threads to native threads with a GVL without a rewrite -- so a rewrite was done. The next rewrite may already be well along: there's been a lot of talk in the community about a GVL-free version of Rubinius as the next mainline implementation.

    64. Re:Review Ruby for the perl enthusiast please by DragonWriter · · Score: 1

      multithreading,

      The Ruby language has fine support for multithreading. The current main implementation uses a Global VM Lock that only allows one Ruby thread to run at a time (native extensions can release the GVL to run in parallel with Ruby threads), but that's an implementation issue, not a language issue. Other implementations (JRuby, IronRuby, MacRuby, now, and Rubinius is aiming for this) have native threads without a GVL.

      UTF support (only just in - enjoy the bugs!)

      Unicode support has been in Ruby since 1.9, which has been out for quite a while; it was a bit late to the party, mostly because in Japan, a key area for Ruby, not just because Matz is from Japan, but because a lot of money supporting Ruby development was coming from Japan, Unicode dominance isn't (or at least wasn't, when the issue arose) as dominant as elsewhere and it was important for Ruby to not only nail Unicode support, but to nail support for multiple encodings (which it did with 1.9.)

      cross platform GUIs (TK or Fox. WTF if Fox?)

      TK and Fox aren't the only cross-platform GUI toolkits with libraries available for Ruby; Qt, Wx, and GTK are all supported.

    65. Re:Review Ruby for the perl enthusiast please by Concern · · Score: 1

      "Data safety" has nothing to do with "easy".

      It can be interpreted that way, because eliminating the GIL and allowing threading makes it "hard" for your data to be "safe" from races.

      The idea of making MRI even slower is hilarious. But I'm sure you could do it by introducing even more locking behavior. Ditching MRI for one of the other, newer RVMs sounds like a fine idea. :)

      --
      Tired of Political Trolls? Opt Out!
  10. Re:I'm sure... by Anonymous Coward · · Score: 0

    Yes, every Linux distro is hipster.

  11. Ruby is for when you want to enjoy yourself by Anonymous Coward · · Score: 1, Interesting

    Ruby can be used for both serious projects as well as providing quick prototyping.
    Ruby is probably _the_ best language to refactor code, but with some minimal care, projects will actually rarely need much heavy-lifting because of Ruby's design-choices, powerful flexibility and lack of syntactic bloat.
    So if you're into Agile, Ruby will grow on you, indefinitely.

    You don't have to use Rails at all. Ruby is ALL INDEPENDENT LIBRARIES, even more so than Perl.
    You SHOULD take a look at *ActiveRecord* though. It rocks if you need to roll your own SQL database that much more efficiently, *all* in-code and commandline deployment.

    Ruby _can_ be used for simple "one-liners", maybe not to the same extent as Perl, but why would you when you could make a short beautiful script. Like, instead of abusing some mythological undocumented features that might change at any time?
    Ruby lacks the UGLINESS of Perl though, so if you require UGLINESS, for Pete's sake: stick with Perl!
    And of course, you won't get raw speed with Ruby, but we got C / C++ to provide that when required, probably in similar fashion as Perl. So with good planning, Ruby can actually scale pretty well in big demanding projects.

    If Ruby's efficient and beautiful syntax peaked your interest, why not just try it yourself on the next task you desire fulfilled? The language lends itself to be learnt very quickly, and for experienced programmers, those that know what they're doing, Ruby provides an extremely short time to productive results.

    I recently tried the other way: A friend recommended Perl (I've been familiar with Perl for over 15 years, however never built something from scratch in it). I made a simple graphical project using Perl docs and googling. The whole ordeal reminded me in so many ways why I prefer Ruby over Perl, or any other language. I was successful in using Perl. It just wasn't a pleasant and enjoyful experience compared to what I'm used to using Ruby.

  12. Re:I'm sure... by enrevanche · · Score: 1

    Since Ruby does not even have a browser plugin, your comment shows that you are just as uninformed as the poster you replied to. The fact of the matter is that security in the browser is hard and all of the solutions that try to run untrusted code in a sandbox have had security problems at one time or another. Java on the server or running standard applications is at least as secure as other languages running at the same privileges. In addition, in the server environment because it inherently protects against buffer overflows it is safer than c, c++ and all of the languages that require substantial c/c++ libraries to gain performance due to slow performance of the their interpreters/JITs.

  13. Re:I'm sure... by Anonymous Coward · · Score: 0

    No, but most of them are.

  14. Really? by Anonymous Coward · · Score: 0

    Can slashdot readers get more childish? Just because it is not their favorite language, they all get butthurt.

  15. OP omits biggest item by Anonymous Coward · · Score: 1

    Refinements, which allows meta programming to be scoped to a particular namespace. This addresses a lot of concerns about meta programming code having too much global impact if done as a "monkey patch" or module include/prepend (which is just a glorified name for a monkey patch that can subclasses from, and can invooverride arched class'smethods instead of rewriting the method on the patched class).

    However, it's released as "experimental" probably because they still haven't figured out how implement this in a performant way (currently it can be slow even by dynamic language standards). Which I think is a big issue - a few months later they may realize there is no way to make it efficient and remove it, by which time many libraries would already use it. I don't think major language constructs should be released as experimental on non-beta releases - either get them stable or don't release them.

    1. Re:OP omits biggest item by HiThere · · Score: 1

      What bothers me is that they don't say that it's truly parallel yet. This probably means that they've still got that fake parallelism in there to keep the libraries happy. They *REALLY* need to solve that.

      It's true that what they introduced in 1.9.? was a lot better than nothing, but it's not good enough with MPUs becomming so dominant. And doing parallelism at the gross level of processes isn't very satisfactory. Threads should have a means of multi-tasking.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  16. Re:I'm sure... by Anonymous Coward · · Score: 0

    In the meantime, the rest of the world is using "big boy languages" that people give a damn about like JAVA and C# and Python.

    The same rest of the world isn't throwing away their time making a bunch of posts about how hipster and Apple centric random other languages are either.

  17. 2.0 released as Ruby turns 20 years old by petsounds · · Score: 3, Interesting

    Happy birthday to Ruby! Pretty cool the way that numeric coincidence worked out.

    2.0 looks like a nice step forwards. I'm not sure where I stand on Refinements yet. I hate the method overriding of base classes that goes on in Ruby land, and Refinements is supposed to minimize the bad affects of that by offering scoped alterations, but from what I've heard there's a lot of side effects. Frankly, I think Ruby needs a 'protected' type; any other solution is just monkeys all the way down. But I could say this about a lot of the popular languages right now.

    1. Re:2.0 released as Ruby turns 20 years old by Anonymous Coward · · Score: 0

      monkeys all the way down.

      Actually, that's the spirit.
      It allows very clever tricks, it make Rubinius possible (basically, Ruby written in Ruby) and it allows you to understand Ruby's structure like no other program.
      If you don't want to use it, don't use it, and pretend that base Classes are all protected.

      Meanwhile, I can extend Sketchup classes in 3 lines, and have fun making my programs fail by swapping the definition of Array and String :

      1.9.3-p194 :001 > Array=String
      (irb):1: warning: already initialized constant Array
        => String
      1.9.3-p194 :002 > Array.new('Hello')+Array.new(' ')+Array.new('world')
        => "Hello world"

  18. Features Schmeatures by Anonymous Coward · · Score: 0

    C'mon folks, it's not about Ruby vs Perl, Python or whatever. It's about what a language allows you to express in an easy or elegant way for the job at hand, within a reasonable timeframe. As a heavy Python and Ruby user, I can say they are definitely very different languages. I like being explicit in Python, and know others won't have to think too much reading my code. But when I write in Ruby I feel like I'm using a beautiful instrument that allows me to express myself in a very pleasing way. Undoubtedly more implicit behaviour, but more concisely. It also has a very elegant object model, unlike Python.

    I believe it is this feeling most Ruby programmers are talking about when they describe how much "fun" the language is to use.

    It is in the lineage of Lisp and Smalltalk as much as Perl or C.

  19. Re:I'm sure... by Anonymous Coward · · Score: 0

    Since Ruby does not even have a browser plugin, your comment shows that you are just as uninformed as the poster you replied to.

    Ruby can be run in the Native Client quite easily, the necessary patches are in the mainline tree.

    In addition, in the server environment because it inherently protects against buffer overflows it is safer than c, c++ and all of the languages that require substantial c/c++ libraries to gain performance due to slow performance of the their interpreters/JITs.

    Sun Java requires a substantial C++ runtime for precisely the same reason. About the only implementation that comes to my mind that doesn't need it is Jikes RVM.

  20. Ruby vs Node.JS by Anonymous Coward · · Score: 1

    Skillset momentum aside, why would anyone choose Ruby over Node.JS?

    Node is *significantly* faster right out of the box (while Ruby JIT is still in its infancy). With so many well-funded implementations (Google, Mozilla, Opera, Microsoft) competing to be a tiny bit faster in any way possible, JavaScript is very likely to remain the fastest dynamically-typed language. Node is also built with a specific emphasis on scalability / parallel performance.

    Node.JS also has the advantage of using the same language on the server that you inevitably have to use on the client end of Web-based applications. This avoids the overlap where you end up writing the same thing in different languages, adding complexity to the project. JavaScript / EcmaScript is also the preferred language of browser extensions, many desktop / mobile widget kits, GNOME apps, QtScript, etc. By focusing on one language instead of several (in a finite amount of time), you'd gain more expertise with that one language and be able to accomplish more things with it.

    Of course JS syntax leaves much to be desired, but that will be revised some time in the future. CoffeeScript's syntax is even more intuitive and compact that Ruby's!

    --libman

    1. Re:Ruby vs Node.JS by Anonymous Coward · · Score: 0

      Then again you could switch from V8 (the fastest JS-Engine ATM) to LuaJIT, which is still 6 - 8 times faster. But the problem with all these embedded languages is, you have no propper standard libraries and minor support for encoding etc. So you have no point here.

    2. Re:Ruby vs Node.JS by Anonymous Coward · · Score: 0

      Yes, I've heard that LuaJIT might be faster than Node.JS, though I haven't seen any definitive benchmarks. If true, it won't be a huge order-of-magnitude difference as it is compared to Ruby.

      Seems that the Node Package Manager has a large collection of modules already, and is growing very quickly. JavaScript itself is vastly more popular than Ruby or Lua, so it makes sense that its leading server-side implementation would get a lot of attention from module developers in the near future. (And the popularity of JS is usually greatly underrated, because people don't call it by a consistent name when talking about "Web scripting", "AJAX", "EcmaScript", "SSJS", "Node", "JScript", "Apple Dashboard Widgets", "Firefox add-ons", "Google Apps Script", etc.) Node.JS is still inching toward that 1.0 version, which would send a signal to a lot of people that it's ready for serious use.

      I'm not here to make any "point" against Ruby, just to present my current opinion and ask why people choose Ruby over the alternatives, particularly Node.JS.

      --libman

    3. Re:Ruby vs Node.JS by Anonymous Coward · · Score: 0

      It is used more than Ruby because of the use in client-side scripting. If Lua, Ruby, Perl could be used in client-side scripting then it might be a hugely different story. Right now there is no alternative to JavaScript in the client-side scripting. While NodeJS is fast I doubt it has a high enough following compared to RoR and is probably on par with Grails in terms of server-side.

  21. Re:I'm sure... by jbolden · · Score: 1

    Please Python was a hipster language 17 years ago. Today stuff like Scala, Clojure are the hipster languages. Even Haskell is getting post hipster.