Ruby 2.0.0 Released | Hacker News Reader

Ruby 2.0.0 Released

ruby-lang.org

546 pointshaven285 comments

Overall, a good feature set. I only see some utility for keyword arguments, admittedly, but I tend to write very functional code, so maybe other people will get more mileage.

Refinements, as I understand them, are a bad idea.

I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior of any given class now can depend heavily on context.

This makes optimization a bitch, for the same reason that it makes programming a bitch. I can now have two Strings, one Refined by ActiveRecord, the other Refined by Sequel, which expose a different set of incompatible methods.

Totally agree about refinements. Hopefully the community pushes back enough on that experiment so it gets deprecated and removed.

A better design approach to achieve this effect is wrapper objects (similar to jQuery and Underscore.js) where I can add functionality to existing objects. Ruby has everything we need for this already, and makes it quite easy to do.

Aren't refinements a "fixer feature", i.e. something 99% of developers should just ignore it until they really get into a problem with badly done monkeypatching, then use it to solve the problem and just move on? Why do people get so excited about them, both in a good and in a bad way? Just use them inside your library code and make sure people using your lib/framework can just pretend they don't exist, keep monkeypatching "chained inside" as your dirty little secret:P)

Charles Nutter does a good job of explaining why you can't just ignore refinements: http://blog.headius.com/2012/11/refining-ruby.html

In summary, they makes the Ruby language harder to implement, and Ruby code harder to understand. You can't pretend they don't exist if their existence compromises the meaning of your code and the performance of your chosen Ruby implementation.

Because they make efficient implementation of Ruby, which is already an utter nightmare, substantially harder.

but ruby culture is already one of modifying builtins, so using wrappers while arguably better, does not solve the issue which refinements solve.

There's been a substantial retreat from modifying builtins in library code in the last 1-2 years anyway.

Refinements worry me too. They make it a lot harder to read and understand code, or track down where strange behavior is coming from. I wish I could just ignore them, but unfortunately libraries like ActiveRecord probably won't. And then there are the performance problems.

Since so many people dislike them, I wonder what the community response will be? Will JRuby just leave them unimplemented? That seems bad, but I'm not sure I'd mind too much. But that's not viable if it means Rails and other things won't work on JRuby.

Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing.

I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember what bothered them, but if that rings a bell for anyone else, please chime in.

There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl:

  sub withCamelize (&) {
      my ($thunk) = @_;
      local *{'String::camelize'} = sub { ... };
      $thunk->()
  }

  sub camelize_and_join {
     my ($str_ary) = @_;
     withCamelize {
        join ', ', map { $_->camelize } @$str_ary
     }
  }

So you can probably already accomplish the same with Ruby's equivalent of 'local' for dynamic scoping.

Wow, that reminds me of the classloader magic Eclipse/OSGi does so that plugins that depend on different versions of the same library can work together in the same JVM.

That kind of local class alteration is very different from the kind of tricks done in OSGi. In OSGi a class is the same no matter what context you're in, it's just that the context you're in affects the look up from class name to class. So all the caching or optimisations you might do against classes are still valid.

Refinements mean things like method lookup are sensitive to the context and become much more fun.

As aardvark179 already mentioned this is different. There are modules on CPAN which will allow you to also do class/module path munging like this and it's fully baked into Perl6: http://perlcabal.org/syn/S11.html#Versioning

Ruby doesn't have an equivalent of Perl's 'local'.

First, Ruby has no built-in way to accomplish dynamic scoping. Perl is Very Powerful.

Second, refinements apply lexically. Consider a class A where refinements have been declared, and a class B where they have not. Class A code calls Class B code. Class B code will not see class A's refinements. In the case of dynamic scope, the refinements in use by class A would be visible to class B code, when called from code within class A.

Yes having dynamic scoping gives Perl a very powerful programming instrument.

And the lack of dynamic scoping in Ruby can cause problems elsewhere: http://news.ycombinator.com/item?id=5072925

PS. I seem fond of dynamic scoping because I've posted lots of examples here on HN: http://www.hnsearch.com/search#request/all&q=draegtun+dy...

The complaints I recall about Ruby keyword arguments were on Twitter:

https://twitter.com/brixen/status/281180931950264320

https://twitter.com/garybernhardt/status/281181122736582656.

Not sure if that's what you're thinking of.

@ch0wn: I'm pretty sure that chao- was talking about the implementation of keyword arguments, not refinements.

That was indeed the complaint: That the keyword arguments are actually implemented as a hash underneath. Still useful for loads of reasons, but hopefully will transition to a more optimized implementation one day.

> but I tend to write very functional code

A bit offtopic, but since you said that and you seem to be both fond of functional programming and in touch with latest ruby developments, you're probably a good person to ask: How the heck do you do "normal/proper" currying in Ruby? And how do you do it with keyword arguments? (I'm trying to compile a list of functional-idiom examples in popular dynamic language, and when I reached Ruby and currying, all the snippets I found made me go "WTF?!"...)

Ruby only has built-in support for currying procs:

  >> add = -> x, y { x + y }
  => #<Proc (lambda)>
  >> add.call(3, 5)
  => 8
  >> add.call(3)
  ArgumentError: wrong number of arguments (1 for 2)
  >> curried_add = add.curry
  => #<Proc (lambda)>
  >> add_three = curried_add.call(3)
  => #<Proc (lambda)>
  >> add_three.call(5)
  => 8

If you want a no-brainer way of currying methods, you're SOL.

That's pretty much it; the only other way is to build a function combinator from a Proc or Lambda:

irb(main):004:0> multiply = -> a, b { a * b } => #<Proc:0x007fe2822029e0@(irb):4 (lambda)>

irb(main):006:0> square = -> a { multiply.call(a, a) } => #<Proc:0x007fe2840746a8@(irb):6 (lambda)>

irb(main):007:0> square.call(3) => 9

You can do:

    "Hello".method(:split).to_proc.curry[""]
     => ['H', 'e', 'l', 'l', 'o']

If you want to even make the receiver an argument it would take a little more hoop jumping, but with a tiny monkey patch you can enable something like this:

    "Hello".curry.split[""]

Have they removed any features?

No, 2.0.0 is intended to be mostly backwards compatible with 1.9.3.

> I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior of any given class now can depend heavily on context.

The current behaviour makes the scope global, and one would simply overwrite the methods of the other, surely that is a worse thing, no?

> Refinements, as I understand them, are a bad idea.

I agree. Some feature to debug monkey patching conflicts is needed. But do we really have to change methods call logic to achieve that goal?

I would like to see some diagnostic feature one can just turn on/off. Something that just shows conflicts.

I do wonder about the long term success of Ruby. Rails is easily the most visible project for Ruby. Rails is big, and all that code represents a high barrier to entry for any framework in a different language that wants to compete. However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion).

Ruby also has utility for doing lots of scripting type tasks (things like Jekyll). The libraries you need to do this are simple to write. Python is perfectly adequate for this task already, as is Node (modulo callback spaghetti). So there is no barrier to entry here.

In summary I don't see any project going forward that provides enough value to maintain interest in Ruby. Thoughts?

[NB: I'm not saying Ruby is going to die overnight. I just think it will slowly become less relevant.]

> Thoughts?

I think most of the things you say sound like you haven't worked with either.

Few people are moving to pure JS front-end. Some are, some write blogposts about it, but the majority of people isn't. Some are even moving back, a year or so ago there were a lot of blogposts about that kind of stuff.

Rails offers a lot of interesting things in the M and C parts of the MVC pattern (Object persistence, REST endpoints, ...). People even write books about the topic ( https://learn.thoughtbot.com/products/1-backbone-js-on-rails )

Ruby and Python are pretty similar and as with Java and C++, there is space for both. I personally like Ruby more, but I guess that's just a matter of style.

FWIW, I only used examples with which I have personal experience. All new front-end projects we're doing are pure JS. I've used Jekyll in various commercial and non-commercial applications.

http://engineering.twitter.com/2012/05/improving-performance...

Great article! Are there any other good resources to read about how best to architect a modern rich web app?

> I just think it will slowly become less relevant.

That's true for virtually anything. Do you think C/C++ or Java or JS will be mainstream 30 years from now. They will be in the same situation FORTRAN is today: important because of lots of legacy code, but not a viable choice when starting a new project.

Of course some of them will never die. LISP comes to my mind. :-)

Sure. It's the time scale that's important. Irrelevant in 30 years has vastly different implications to irrelevant in 5.

>Of course some of them will never die. LISP comes to my mind. :-)

Or, to put it another way, LISP was never alive to begin with.

If Ruby/Python had a community and third party libraries the size of LISP we would consider them mostly irrelevant languages.

> ...we would consider them mostly irrelevant languages.

And apparently "we" are using "irrelevant" to mean not fashionable. Or does it mean, "Do not use for new IT projects" or something? What does it matter what other people do, especially those with a strong (if small) community, frameworks, libraries, books, articles, conferences...

And where does Smalltalk fall? I hate to tell those people their language is "irrelevant" -- will their programs crash? And which LISP, by the way?

This irrelevance property is dumber than a language debate because we don't even debate them, we condemn them from the outside by applying our own arbitrary criteria. Why do we need to belittle the work of others? Maybe we are not as sure as we appear.

>And apparently "we" are using "irrelevant" to mean not fashionable. Or does it mean, "Do not use for new IT projects" or something? What does it matter what other people do, especially those with a strong (if small) community, frameworks, libraries, books, articles, conferences...

It matters because there is not enough of "community, frameworks, libraries, books, articles, conferences". If I want to do something in LISP there are 2-3 libraries in different states of broken and/or abandoned. In Python I can usually find something with much more ease. In Java even more so. The same for hiring programmers AND getting hired yourself, etc etc.

>And where does Smalltalk fall? I hate to tell those people their language is "irrelevant" -- will their programs crash?

You don't have to tell them. They know it already. It has been ever since most Smalltalk shops closed and the bigger ones turned over to supporting Java.

Now, people using Smalltalk to do hobby work, or even nice important work with paying customers, good for them.

Their programs will not crash (unless their Smalltalk platform of choice gets abandoned to die with too few contributors or is proprietary and doesn't get support for newer platforms and architectures). But they wont be getting as much new toys as the other boys.

>And which LISP, by the way?

All of them, inc. Common Lisp. Clojure might have a fighting chance, but it still is too small for people who value ecosystem over cowboy style "let's build all the wheels ourselves".

>This irrelevance property is dumber than a language debate because we don't even debate them, we condemn them from the outside by applying our own arbitrary criteria.

Irrelevant? It's very pragmatic. Number of available employers, employees, number of documentation, vibrancy of the ecosystem, new libraries and continuous support for older libraries, etc.

I would love to have a Smalltalk that is well supported to play with. One that is not aimed at kids and doesn't have a Fisher Price UI like Squeeze, and that can match Python or Java for ecosystem. Unfortunately none exists.

I appreciate that you write really well, but I think your argument boils down to "there's safety in numbers."

And that is a totally valid strategy for IT careers, but I would quit programming if I had to follow that advice. It feels too much like, "Stick with the herd." Just one person's opinion.

C and C++ will very likely still be "mainstream" 30 years from now.

Essentially every important piece of software today, from operating systems to programming language implementations to server software to applications, is written in one or both of them. All of these systems are not just going to go away.

C is over 40 years old, and C++ around 30, yet in that time nothing has come along that can compete with them. Some other languages have tried, but their success has only ever been partial, and typically in just one or two specific domains.

Go is making a strong go at it. No pun intended.

Go hasn't really seen much success. It isn't as obscure as many other languages, and being supported by GCC does help it out, but we haven't seen any major adoption of it. Maybe that'll change at some point, but it doesn't look very likely.

The rumours of Fortran's death are greatly exaggerated.

People still write new code these days in Fortran for scientific computation. Fortran compilers are still markedly better at optimizing numerics, multi-dimensional arrays, etc, partially because of the effort invested in the compilers and partially because the language is easier to optimize.

It's definitely a niche language.

I used FORTRAN at NASA as late as 2003. Id be surprised if they were not still using it. It was painful, though.

Lisp has had keyword arguments since at least the 80's. Ruby 2.0 adds them and this is supposed to be the "new" hotness? Get off my lawn!

Lisp will likely remain alive, but never as a mainstream language which really defeats the whole purpose.

rails may be the most visible ruby project out there (and indeed the "killer app" that got a lot of people and businesses into ruby), but it is by no means critical or even necessary for ruby's continuing success. check out puppet's userbase, for instance - there are some huge companies using it to manage their deployments. jruby could well become one of the go-to jvm automation solutions down the road; it's certainly doing everything right to get there.

but more than any of that, ruby is simply the most productive language i've encountered for performing quick one-off tasks and exploring algorithms. it has all the strengths of perl (another language that plays very well in this particular niche), and adds very natural support for both object-oriented and functional approaches. i've used lots of languages (everything from basic to haskell) and ruby is almost unique in that i have never felt like i was fighting with the language to put my ideas into code. i think of the way i'd like to say something, and sure enough, ruby supports it and more often than not makes it easy and natural.

RubyMotion is actually pretty cool. So far, the adoption of RubyMotion isn't too bad.

Agreed. As is MacRuby, though it doesn't compile down like RubyMotion. As is Hamish Sanderson's RB-Appscript (AppleScript replacement), although the deprecation of carbon events has sunk it sadly.

As a Ruby user that finds Rails annoying and not something I like working with, I don't think that's all that relevant. A lot of people have come to Ruby because of Rails, but a lot of Ruby people dislike Rails too. There's a plethora of web frameworks for Ruby that have sprung up exactly because of people who want to use Ruby but don't like Rails.

In terms for barrier to entry with Python, the issue is that a lot of us chose Ruby over Python already for very specific reasons. Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me.

Ruby is the project that provides enough value for me to maintain interest in Ruby, and that's what I see with lots of other Ruby users too: The language is sufficiently more fun to work with that we're willing to put up with quite a lot, including horrible performance, to work with it.

Ruby might become less relevant to others, but I don't care if that were to happen. It will only become less relevant to me the day a new language comes along that is even more pleasurable to program in. So far I've not seen anything get close.

I have a habit of bringing up this page every time I hear someone talk about Python whitespace. I'm not sure if you've read this, but here it is anyway.

http://www.secnetix.de/olli/Python/block_indentation.hawk

Summary: Python's whitespace usage is nothing like Make's.

You seriously would turn down a good job or other opportunity if the only downside was having to write in a whitespace-sensitive language?

Most of the good developers I know have their preferences for sure, but can be productive in all sorts of languages.

There are plenty of other good jobs that don't require Python. He has already said others like it but it doesn't work for him personally. Why beat it over his head for your preference?

Because sometimes, assertions seem to be so absurd, that they require clarification. If someone said, I would NEVER program in Ruby, because Hash Rockets, I would ask the same question.

Python has enough other design mistakes (statements vs expressions, destructive sort by default, and crippled lambdas to name a few) to keep away anyone with exposure to a more functional style even without whitespace issues.

Python is a functional language. They are not design mistakes, but merely things you disagree with. Lambdas aren't "crippled", for that matter. You can throw about "normal" functions too, you just don't have the convenient expression syntax.

There is no reason to include statements in a language other than inexperience.

I can't agree with that. "break", "exit", "return", variable declarations, etc. should never be expressions.

The choice of whether to implement language constructs whose very semantics require that their return value be un-observable is completely arbitrary. Why make your language more complicated in order to support something that by definition has no effect?

Of course things like crippled lambdas can be worked around by using a named function, but the fact that you have to do that in the first place tells you that the person implementing lambdas did so without at the time understanding what they were for.

Anyway, it's fine for some kinds of imperative programs, but calling it a functional language is misleading.

The gp said "I'm not touching it." and you seem to have read "I can't be productive in it."

Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me.

This has to be up there with people claiming they don't like Lua because array indexing starts at 1 instead of 0. Of all the weaknesses of Python, focusing on something so superficial just seems lazy.

Perhaps in the future just say that you're experienced and comfortable with Ruby and have no reason to investigate Python at the moment. :)

Python's whitespace-as-logic means that, for any given project, every editor used by every developer needs to have the same the same definition of what a "tab" is, because mixing tabs and spaces can introduce logic errors.

You can reasonably argue that a project team should already have and enforce a coding style guide, so specifying a "tab" isn't a big deal. But what if you're part of two separate projects which different coding standards? Do you use Editor A for Project A, and Editor B for Project B? Or do you maintain separate configuration profiles, one for each project? Granted, this also isn't a big deal: Just "git checkout ProjectA" in the directory where you keep your preferences before you start coding. But it is an extra step in your workflow.

You can use the "-t" or "-tt" flags to spit warnings or errors if someone mixes tabs and spaces, so any conscientious group can easily catch whitespace incompatibility problems. But Python's whitespace usage has organizational consequences, and it can affect a developer's choice of tools and/or workflow. For some people, this is not a superficial impediment.

This is a non-issue. Just follow PEP 8, which clearly suggests to "Use 4 spaces per indentation level."

PEP 8 has been around for over a decade, so there's no excuse for not following its recommendations.

Even Rubyists always use 2 spaces, no tabs, even though whitespace is (mostly) insignificant.

Having to follow a indentation spec just to ensure your code runs is too much rigidity to ask of a programmer.

No, not really. All projects involving more than one coder involve coding standards, and practically all languages have a single set of well-defined coding standards(Go, Python, Java, C#, among others).

Coding standards are the most time-wasting form of bicycle shedding. Choose one and stick with it. gofmt is fantastic, and so is PEP8.

I prefer my white space to not mean anything because I normally can't see it. If I show white space then I see meaningful and non-meaningful white space. I find this aggravating and figure the designer of such a language is a control freak who will likely continue to aggravate me in other stupid ways. I don't need this in my life. I don't know how this disagreement between myself and the language designer seems 'superficial and lazy' to you.

ialsoagreewiththisandfindthatshowingwhitespaceisacompletelyunnecessarythingandonlygetsinthewayofhowawesomelysmartiamtobeabletoreadallthecodeiwrotewithoutanywhitespaceinit

Your text is breaking the page. I need to flag this, sorry.

(And HN needs something to stop this happening.)

We're talking about white space as a source code token, not as used in written verbal languages.

You can compare the trivial differences all you want, but the truth is, they are real differences in the way you think about your code and programming.

Indexing starting at 1 is not only irritating, it's mathematically difficult. Certain concepts actually can't be described (as easily) with array indices that start at 1. It's not a trivial argument.

Similar with white space; having to write code which obeys white space and tab rules is not the way some people like to think. As much as I love Python (and I do), I find it more restrictive and less fun than Ruby. It's not just superficial, it changes the way you think, and what you think about. Of course Python has its advantages, lots of them. But it also has its own style, which may not be everyone's song and dance.

I do program in both Python and Ruby frequently, and I have to say that it has nothing to do with experience or comfort, it's truly a judgement, and a valid one at that. Nice try :)

I would love to see an example of a large project in another language besides python, that uses frequent cases of non-pythonic indentation.

Sure, there are certain edge cases when I wish I could represent something all in one line, or something similar, but they are so few and far between that I really cant see it as a major argument against not wanting to use python.

I felt the same way about whitespace at one time, but then I got used to it, and wonder why I ever felt so strongly one way or the other. The cases when my indentation isnt exactly like python in other languages is very rare.

If you find yourself using frequent cases of non-pythonic indentation in other languages, you may be writing some very unfriendly/unreadable code in a lot of instances.

It may make sense to you, but I wouldnt want to work on the same team.

The problem is something like this. There is a cancer patient and he complains of head ache, the family members around give him a Paracetamol 500mg. The family members now also expect that Paracetamol just given will also cure him of cancer apart from curing his headache too.

Python people constantly advocating white space indentation as some kind panacea to all programming problems programmers have ever faced is irritating to those people who know it is not and can never be.

Also look at what is happening in this thread. This thread is about Ruby, every time some thread on Ruby or Perl is started- You see Python trolls descending all over the thread to push their shiny tool down others throat. I mean this is happening for years now, may be even decades. There is also this quote...

"And what defines a 'python activist' anyway? Blowing up Perl installations worldwide?" - Ivan Van Laningham

http://mail.python.org/pipermail/python-announce-list/2005-J...

That is how notoriously Python people troll on other languages.

Trolling on other languages is a irritating thing, sooner or later people figure you have nothing to offer. Instead of doing this and trolling on other languages, may be the Python community should build about something awesome and let people decide if they should use on its merits.

You should note that there's a huge gap in the definition in the English language between "trolling" and "defending".

Also, stop putting your words into other people's mouth. Who here is advocating Python indentation as a cure-all? Point is, you can talk about Ruby all you want, but when you diss on Python indentation, you'd better back up your opinions with facts instead of substituting your opinion as facts.

The only valid reason to diss on Python indentation is if you find yourself constantly writing really long functions in multiple nested blocks. You'll have trouble seeing which block you are closing the further down you go.

Now we are done defending, I still haven't seen a valid argument against Python whitespace, or people who have the guts to say they just don't like it.

What exactly are Python defending in a "Ruby 2.0.0 Released" thread? What is the there to defend here? The title is "Ruby 2.0.0 Released" not "Ruby 2.0.0 Released against Python".

Why did the OP of this thread even question the relevance of Ruby as compared to "Python". And why is it that only Python people feel a need to do that in every thread on other languages? Its always the Python guys who do this, I never see any Java, C, C++ or Perl guys do this.

This has become very common.

The way I see and this very theme, is pretty re current in every language thread.

>>I still haven't seen a valid argument against Python whitespace

I still haven't seen a valid argument on why Python people need to descend on every language thread and start this discussion. Even if the topic has nothing even remotely to do with Python.

>>or people who have the guts to say they just don't like it.

Or people who have the guts to see an opportunity on every language thread, then descend and do marketing-through-trolling.

Do you even know how forums work? Did you even read this thread? When I click the reply button to levels down am I replying the parent comment or the OP?

The sole reason I'm here is to find out what's new and fun in Ruby. The reason I'm replying is because I see people spreading FUD again about Python's whitespace rules without anything to back it up.

I've seen tons of derogatory names Java, C, C++ people call Pythonistas, Rubyists and Perlists scripting kiddies and such. I've seen some pretty prominent Perl hackers (Sam Tregar and others) complaining about Python's range start at 0 and such.

Stop living in a paranoia bubble and think everyone is against you.

For all intensive purposes, Python and Ruby are practically equivalent. So equivalent, in fact, that we have to find absolutely pointless differences to argue about since there are no actual significant differences worth mentioning.

No one is against anyone. Python is great. Some people dislike whitespace restrictions. Who cares? Just because they dislike a characteristic of your preferred language does not mean they think it's lesser or are trying to demean or belittle it in any way. Stop arguing about it already.

As you said, "Stop living in a paranoia bubble and think everyone is against you."

> Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me.

So you've never even tried it? If you like YAML, SASS or CoffeeScript, you would like Python's indentation syntax too.

I think it's lovely and elegant, and that meaningful indentation should be used more. It obviates a lot of cruft and makes things clearer and more concise. What's not to love?

Seriously, it's kind of dumb if proudly holding on to your prejudices is preventing you from enjoying a lovely programming language.

It's a weird jump of logic to say that because the biggest Ruby project (Rails) is overkill for a particular architectural flavor (JS + REST backend) that this will lead to Ruby's decline. Even assuming the market moves wholesale to pure REST backend (which is quite unlikely frankly, because not everything on the web is a CRUD-heavy app, documents still dominate), and Rails does not fit the bill (which is also arguable since moving to pure REST API only makes views/helpers irrelevant, which is at best 20% of Rails), then you would see other frameworks like Sinatra/Padrino rise to prominence.

The only way Ruby becomes irrelevant is if a new paradigm becomes dominant that just isn't easy to implement in Ruby. Threaded/evented/asynchronous frameworks do fit the bill, but my sense is that enough people prefer Ruby so much to a language like Javascript (in the case of Node), that if something like web sockets become indispensable as an 80% use-case, then the Ruby community will figure out how to make it easier to use them. I'm still using MRI which has some difficult problems to solve, but it seems JRuby is pretty much ready to pick up the slack if it really becomes necessary.

>However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion).

I agree with this but I think there is a place for a javascript framework tied fairly closely to Rails. Possibly ember.js since the attitude towards both seems similarly opinionated and Yehuda Katz is one of the ember team. The Rails API gem accommodates this quite nicely as well although one of the benefits of Rails' modular design is that you can lose lots of the stuff you don't need if you are only building a REST API. Maybe this is the future of Rails?

I maintain rails-api, and both Yehuda and I have commit to Rails. I just want to mention that while Ember + Rails will be a potent combo, Ember will work great with non-Rails backends as well, and rails-api will work great with other frameworks too. That said, we're working really hard to make sure that Rails 4 + rails-api + Ember 1.0 is a fantastic experience, so watch that space for sure.

Thanks for all the hard work Steve. I have been waiting for ember 1.0 to really give it a proper go but I'm looking forward to it. It seems like a slightly steeper learning curve than something like backbone but I'm sure it will do more for you once you get to grips with it.

The peepcode on Ember is really worth the $12, it's a great introduction. I really believe in what Ember is doing quite a bit.

As far as Ember vs. Backbone, it's like Rails vs. Sinatra: Backbone is 'easier' but then you have to write a ton of stuff yourself. Ember has more going on, but you write a lot less code.

But where Ember really shines is the way it deals with URIs and routing. I think it's super far ahead of other JS frameworks in this respect, and I hope routing.js sees some pickup.

> In this world Rails doesn't deliver any particular value (in my opinion).

I beg to differ, though I'm biased. Rails still offers a lot. https://github.com/rails-api/rails-api#why-use-rails-for-jso...

The pure JS front-end approach has its advantages, but it adds a lot of complexity for advantages that don't necessarily matter. Oftentimes if not always, you get better results by rendering the HTML server-side rather than client-side.

I'm more worried about Javascript. Unlike Ruby, which has genuine advantages separate from Rails, Javascript is almost entirely propped up by its status as the only language available for DOM manipulation. Once it loses that footing, it's not a very viable language in and of itself.

I work in Ruby and Rails. I can much more easily imagine moving away from Rails than from Ruby. It's such an enjoyable language to work with that I doubt I'll ever put it aside.

Your argument has this implicit assumption that, all things being the equal, people will choose node.js and Python over Ruby. I don't think this assumption is valid in the slightest and I think it's just showing your own bias.

Of the three I think Ruby is the better language. I still like Perl though, so what do I know. :-)

I always put python and ruby on par, too. I think there are various language features that attract you to one or the other. I find ruby an incredible fit to the way I like to be creative.

I find that the ruby community tends to be fairly vibrant, passionate and innovative. I think the language lends itself to a creative way of thinking, and that shows in the projects that are created in it.

Blocks are amazing, and really clean up code for what is a very common usage pattern. I'm semi-offended by python because of the lack of what I deem to be an elegant equivalent. Not as offended as I am by perl or java, but I used to like those languages too. I detest the python string interpolation syntax - #{} is so much nicer. And I suspect that for other people these choices matter too.

Why weren't things like Sinatra, Sass, Less, Jekyll, Metasploit and Rails invented on another language? Other languages would be adequate for the task as you put it. Github is arguably the biggest thing to happen to open source in recent years.

As far as JS front ends/Rails go, I think we could get there one day and there are tradeoffs but you have a few problems with the model you propose; 1) Javascript sucks as a language 2) Server side rendering is always going to give you more control 3) accessibility is easier if you have a server side fallback.

"Best Practice" has always switched between centralised and decentralised throughout the history of IT. With Rails you can do both.

Basic Ruby 2.0 benchmarks calculating pi from gist [1]

$ ruby --version

ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1]

$ time ruby pidigits.rb 10000 2>&1 > /dev/null

17.51s user 0.11s system 99% cpu 17.639 total

$ ruby --version

ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1]

$ time ruby pidigits.rb 10000 2>&1 > /dev/null

4.64s user 0.27s system 99% cpu 4.927 total

That's a significant difference in speed. Going from 17.51 seconds to 4.64 seconds

1. https://gist.github.com/thoughtpolice/5025417

If we see these sorts of improvements overall, then this is a very exciting update

Agreed. Testing against some of my production apps now to get a better feel.

How did it go?

I've also seen a speedup in Rails app boot time (the require optimizations):

1.9.3-p194: 11.8s

1.9.3-p385: 9.9s

2.0.0-rc2: 6.1s!

Tests were done with `time bundle exec rake environment` 5 times, dropping the highest and lowest and getting the mean of the rest (lazy snow day benchmarking). Very exciting!

Thank you for trying. What script `pidigits.rb' do you use?

Most likely it was this script: http://benchmarksgame.alioth.debian.org/u32/program.php?test...

Not tried 2.0 yet but got very significant speedup of 1.93 (about 3x) when I enabled optimisation in the build. Were the build settings similar for both versions in your tests?

This is pretty exciting. Might be too early to tell, but it feels like the Ruby versioning recently has been done very right. The switch from 1.8.x to 1.9.x was slightly painful, but I think 80% of Rubyists have made the jump.

I'm hopeful and expecting the switch to 2.0 by 80% of Rubyists in 2013.

Compared to the adoption of major version releases by Python/Java/C#/PHP, I think that's something the Ruby core release team can be proud of.

1.9 was not supposed to be a wide release, and it contained more breaking changes than 2.0, IIRC.

I'm not 100% sure on the history, but I believe 1.9.x started as a dev release and then they changed their minds and decided it was a wide release. That initial confusion might be why the community took the time to go from 1.8 to 1.9.

I think they've learned from that, as 2.0 looks like a much cleaner/easier transition.

On the other hand, it means we've now had point and minor releases that broke everything (1.9, 1.8.7, and I think even one or two of the 1.8.7 patch releases actually backported breaking 1.9 features), while the major release is apparently one where nothing from the prior release should break. I'm not convinced that means they've 'learned their lesson' so much as that they still don't know how to version things.

We'll see how 2.1 goes, I guess.

Indeed. I hope that ruby itself starts following the semantic versioning [0] that is so popular with ruby developers. Now that they have a "clean slate" with a 2.0.0 release, they could!

[0] http://semver.org/

Rails 4 will ship with "1.9.3 required, 2.0.0 recommended," so I'm expecting that to drive a lot of adoption.

Not sure what C#'s doing in that list. Think you have some outdated ideas about that community, there's not been a significant breaking change forever.

There are some nice features here:

Keyword arguments, which give flexibility to API design

This looks good to replace all those options hashes in rails for example, though I wish they'd made it an all or nothing thing, apparently you can still do this:

    def foo(x, str: "foo", num: 424242)

i.e. use some named and some unnamed in the same method which looks ugly.

Module#prepend, which is a new way to extend a class

Compared to something like Go, I do worry the Ruby inheritance picture is becoming overly complex, but I guess there must have been some use case for this - anyone know where it is going to be used?

__dir__, which returns the dirname of the file currently being executed

This is a great little enhancement which means I can replace File.dirname(__FILE__) from the start of a lot of utility scripts. Would love to have seen more little improvements like this.

The UTF-8 default encoding, which make many magic comments omissible

At last! This should have been in 1.9.

Performance improvements

While these are incremental, it's nice to see more improvements - thanks Ruby team!

Onigmo, which is a new regexp engine (a fork of Oniguruma)

Not sure what this changes from Oniguruma.

Refinements

Refinements seems to be the headline feature for a lot of people, but I have two hesitations about it: it's encouraging a practice which has come to be seen as one of the most dangerous parts of Ruby - monkey patching, and the process of deciding its inclusion seems to have brought about a few schisms with the community developing alternative Ruby implementations because of performance implications, and raised wider issues about the Ruby design process:

http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-d...

There is the argument of course that it's attempting to limit monkey patching and therefore limit the damage caused, but should it be encouraged at all? It'd be interesting to hear more on what happened here from anyone has been following this closely.

Module#prepend doesn't look too bad from me from a complexity perspective - inheritance in Ruby boils down to two parallel trees: One of the inheritance chains, and one of the method lookups. Really we're dealing with a single tree of "actual" inheritance, with some of them being "hidden" in some contexts. It gets a bit complex if you want to do meta-programming or do something that depends on the inheritance hierarchy, but mostly it behaves the way people expect in regular use.

Refinements, on the other hand, looks brain-damaged to me. I see the rationale, but the outcome looks more complicated and error-prone than the situation it is trying to address...

And it looks like the type of thing that will "infect" other code, just like C++ code for a while got infections of throw specifications on member functions, that then got propagated all over the place and cause major pain every time you tried to modify code. Until most people stopped using them much again except in very limited circumstances.

Yes it's not hugely complex, but it does complicate the composition side of code inheritance a little more as you have to think about how a module might be included as well as which modules and which superclasses you have. Contrast this with go which has no inheritance and only simple composition and is vastly simpler to comprehend re the reuse of code due to those limits.

Re refinements I agree and find it worrying that it was added given the widespread objections.

There was a post here a while ago about a language that didn't use 'super' inside subclassed methods, but instead had something used in the parent class method to call the same one in any subclass. I quite liked the idea of that.

Looks like Module#prepend is there to do a similar thing.

Mixing keyword and non-keyword arguments isn't entirely ugly. It is in the "foo" case since "foo" is deliberately meaningless, but when there's one principal argument and the other arguments tweak or override the method's behavior, it's fine.

I like the idiom of mixed named and not named parameters in Ruby. You don't really need names for implied, required parameters. Consider:

    protagonist.throw(potato, :force => 3, :at => zombie)

In this case a call to :throw without an object to throw is nonsense. Throw is a transitive verb, and the parameter is implied. On a throw method, the parameter is obviously the thing being throw'ed.

On the other hand, the optional parameters are totally obscure, and need to be named.

Similarly:

    justice.join_in_matrimony(jay, bob)

The two unnamed parameters here are the things being join_in_matrimony'ed.

In other words: unnamed parameters are for direct objects, named parameters are for adjectives and prepositions.

Although arguably the Rubyish thing to do with prepositions is chain them:

    protagonist.throw(potato, force: 3).at(zombie)

yes I see your point, it just feels inconsistent somehow, as named parameters are nicely self-documenting, could be used to generate docs etc, but that's probably just a foolish consistency. In your example you could be cute and have something like:

     protagonist.throw(a: => potato, :at => zombie, :force => 3)

which would be just as nice. But I'm sure there are places where this will be useful/necessary, in your chained example with single args it feels forced to have to name them.

Speaking of the video you posted, go to 8:43.

"I know someone who is working on a Ruby implementation and making very good strides and is not talking about it publicly at all--and I think you'll be surprised when you find out about it."

Is Brian Ford talking about Topaz [1]?

[1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/

Probably, yes. If you hung out in #rubinius over the last year, you'd see Alex Gaynor hanging out.

A very common use case for Module#prepend is for mixins that want to decorate methods.

For example, say I have a class that can process stuff, and a mixin that attempts to log calls to the #process method:

     class Processor
       def process
         puts "Very important stuff here"
       end
     end

     module Logger
       def process
         puts "Entering process."
         super
         puts "Leaving process."
       end
     end

If you just ``include Logger`` in Processor it won't work: Processor#process is looked up before Logger#process. However, if you use Module#prepend, the ancestry chain will change and calls to Process#process will be decorated as expected.

Thanks for the example.

And this day shall be know as Ruby Two's day.

I've been waiting for that for a long time ._.

my personal best new feature is:

"The UTF-8 default encoding, which make many magic comments omissible"

because i'm from Germany and we had to add: # coding: utf-8

in every freaking controller to get our german stupid letters (öäüß) to run without problems.

so i'm looking forward to my next project where i can use 2.0 from the scratch.

thank u!

Agree. Everytime I do locales in Vietnamese I have to do the "magic encoding". Not anymore. Fsh.

Why are you writing special characters in your controllers?

We are Danish, and are writing comments in English, and all locale strings is placed in i18n-files.

Anyone know if it is made default for regexps as well, or will we still have to do add /u to every regexp?

Anyone have any thoughts on why python and ruby are so similar, yet so far apart? They are obviously very close, because people switch between them all the time. And they are compared on everything (languages features, libraries, tooling...). I think it's a healthy competitive environment.

I'm a huge Python fan and there is nothing in the world that would force me to switch to Ruby =P

That's exactly what I mean. People feel very strongly for one or the other. Yet, even you, can't deny that they are very similar! Compare them to Java, Lisp, C, Go, Haskell, Perl,...

Actually, I'd lump Perl in with Python, Ruby, and Javascript. They're all at about the same "power level" and have more or less the same built-in types and language features. They all have their own personality but if you only know 1 of the 4 you're still perfectly capable of writing any program that will be more or less equivalent to someone writing the same thing in one of the other 3.

This thread is full of people saying "I use (python|ruby) and (ruby|python) seems fine. There's just no reason to learn it" and you respond excitedly to this comment as if it's representative.

http://en.wikipedia.org/wiki/Confirmation_bias

The above comment happened to be one of the first responses. The others came later. That's why.

People feel very strongly for one or the other. Yet [you] can't deny that they are very similar

It's their very similarity that gives rise to the strong feeling. René Girard's theory of mimetic rivalry sheds light on this.

Edit: Alternatively, http://en.wikipedia.org/wiki/Narcissism_of_small_differences

I was thinking about this lately a lot as I started doing some Python after almost 10 years of Ruby, I think it boils down to the simplicty vs. elegance tradeoff. If you want to have elegant, very high-level APIs that hide a lot of details, like Rails with has_many :posts in class definitions etc. you have to sacrifice simplicity and transparency - this is what defines Ruby in comparison to Python, in hundreds of places Ruby chooses to be elegant sacrificing simplicity when Python does the opposite. As a result Ruby code is often a bit shorter and reads a bit more easily but Python runs faster and makes it easier to understand the code in its full detail, since there is much less "cleverness" going on behind the scenes.

The unfortunate thing is that there really isn't a tradeoff if you build your elegant and simple DSL on top of a set of API primitives that give you access to low-level behavior.

Look at Hibernate. As of the last time I used it (admittedly, several years ago), it was almost impossible to run raw queries against the underlaying database and get back simple result sets as arrays of tuples. You had either the abstraction, or nothing.

With ActiveRecord, you can at least get at the underlaying database connection via select_all and select_values, and turn Relations into SQL queries via '#to_sql'. It's not perfect by any stretch, and for some reason I don't understand Arel decided that being able to OR two queries together wasn't important, but you can leave the abstraction when you need to.

(Mongoid, the MongoDB ORM, is actually really well-designed in this regard; the Mongoid::Criteria works like Arel should, as does Sequel...)

Sorry, but Hibernate has been far superior to ActiveRecord from day one.

ActiveRelation is very similar to the criteria api, but it still uses string parsign.

HQL is awesome.

That said, I haven't done Java for 3 years and am a 100% rubyist (and some lua)

The developments of rails are good. But they are simply all the stuff that maturing platforms will need. Rails is becoming JEE, but in a more developer friendly way. This is a good thing.

> it still uses string parsign

This is false, at least after tenderlove did all his work to re-write arel.

Keep in mind that I'm not an ActiveRecord fan; the internal architecture drives me nuts, but I do like that I can use SQL when I want to, without ActiveRecord getting in the way.

Here's the first Google hit I came across when looking to use PostgreSQL fulltext searches under Hibernate:

https://forum.hibernate.org/viewtopic.php?p=2447426

That's 50+ lines of code, plus some XML configuration, spread over four files, to perform a highly database-specific task that could have been better handled in raw SQL in a single line of code.

Also if I remember correctly, Hibernate, like DataMapper, requires that you specify your field types in the code, which makes migrations (updates to the DDL) a royal pain in the ass, and migrations are an important task in the operational lifecycle of an application.

I'm a big believer in having sole sources of truth, and so I treat the database as the only source for information about the structure of the database -- I don't want to have to specify that information in two places, where it can get out of sync.

Now, it's been years since I touched Hibernate, and it's probably gotten better. But from what I can tell, the above issues are design decisions; part of a conscious effort to hide the internals of the database from the developer, no matter the cost.

This is why people claim that ORM is an antipattern. Because, while an ORM solves 90% of your problems, for that remaining 10%, nothing beats being able to talk directly to the backend.

That 50 lines is adding functionality in HQL.. How much work is it to add a fts() method to active relation + active record?

To execute custom sql, simply:

sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").list();

one line of code.

I think maybe different communities attract and cultivate people with different sense of aesthetics. I originally learned Django and have been picking up a little bit of RoR. I never found the additional context-specific RoR "magic" to be particularly elegant. It definitely reduces the number of lines of code, but I think to be elegant you need be as concise as possible while still remaining clear.

What do you mean by "so far apart"?

I think they are very different too... I just can't explain how or where. Some people SWEAR by one of the two, and refuse to use the other. That's pretty harsh for languages that similar. There must be a reason... (The simplicity vs elegance argument makes sense)

Edit: I think I mean the communities are far apart.

https://en.wikipedia.org/wiki/Narcissism_of_small_difference...

That actually might be it. Very interesting. Thank you!

(Makes me think of Scheme/Clisp too)

> Some people SWEAR by one of the two, and refuse to use the other

Meh, I use Ruby for most of my work (day and side projects) but have nothing against Python. If I was writing a script for something on the OS I'd probably use Python.

Some people just really want to feel part of a group, I guess, and publicly dissing "the other" makes them feel more included in that group, or something. As for me, I like to feel like part of a group too, but it's a more inclusive "programming" group, rather than focussing on any one particular toolchain.

I'm a rubyist. I have nothing against python at all, but I have zero interest in learning it. Why? Simply because if I'm going to devote mental capacity to a new language I want it to be more different. Haskell is my current choice because as far as I can tell it is the opposite of Ruby in every way except the one that is my primary criteria for interest in a language: concision.

I think the true measure of a language is how little it makes you swear when trying to make changes to your own code that you wrote a year ago.

That's positively koan-like in terms of the sheer number of independent factors aside from language that could impact that metric.

The more I think about it the more I believe concision is overrated and borderline dangerous. Shaving a few keystroke today very often means great troubles later.

I used to like those hello world concision contests, but in fact who cares? Who writes a single hello world code? What we need is a language solving the real problems met in most codebase, and I'd say the biggest fish here is the dependencies mess.

I mean concise compared to Java. The reason is because I want to primarily use vim and not need an IDE.

If you spend your day typing the same stuff for a simple program, or you need an IDE to be happy, that is a language failing in my opinion.

The less bloated the core syntax is, the clearer your ideas are which makes your code easier to read. I'm not saying methods should be arithmetic symbols - I think short words with not much syntax around them makes for more readable code.

ruby tends to read like pseudo-code, which is a great way to express the code idea of your algorithm when you're thinking about it, and when you're reading it back later.

Fair enough, but then what we want is readability, which is related but not equivalent to conciseness.

I often have discussions with colleagues about different coding idioms in Python, and I hear often "this one is better because it is less typing". I don't think this is very valid. If everything is equal, then sure, go for less typing. But using locals() instead of explicit arguments when calling a template rendering because "it is less typing" seems not strong enough an argument to me.

I totally agree, and if people think something is better because it's shorter, they are missing the point. But if all other things are equal (and they rarely are), I think shorter is better.

I picked Ruby because it was sufficiently different from C and C++ to be interesting. I got to write much shorter code, for example.

I stay away from Python because it is similar enough to not give me any great benefits over Ruby, while it has some warts (to me) such as the whitespace handling, that makes it uninteresting because it is so similar that the payoff in accepting what I consider warts is too small to warrant it.

I'd have been a lot more willing to ignore the things I don't like about Python if the differences in other areas were major.

That's because the languages are so similar. There is very little reason to become expert at both.

If Python vanished/became closed source/stopped being used tomorrow, I'd most likely switch to Ruby as it's the closest available language. Ironically, this similarity is exactly why I am least motivated to get into it. Why invest the time and effort to learn a new language, idioms and ecosystem that have almost 1-1 equivalents in a platform I know inside out for 8+ years?

When two things are very similar, people tend to develop stronger feelings about the differences that remain.

I once discussed the phenomenon that is precisely communities with adjoining territories, and related to each other in other ways as well, who are engaged in constant feuds and in ridiculing each other -- like the Spaniards and Portuguese, for instance, the North Germans and South Germans, the English and Scotch, and so on. I gave this phenomenon the name of "the narcissism of minor differences", a name which does not do much to explain it. We can now see that it is a convenient and relatively harmless satisfaction of the inclination to aggression, by means of which cohesion between the members of the community is made easier. -- Sigmund Freud, Civilization and its Discontents

http://www.historyguide.org/europe/freud_discontents.html

Ruby is Perl as it always should have been. Python is a dynamic variant of a better Java.[1]

These result in two very expressive and potent languages with many similarities and with a lot of the best ideas of modern programming languages included (pure functions, lambdas, list comprehensions, etc.) but with fundamentally different core "belief systems" and zeitgeists.

Ruby is very, very much a "there's more than one way to do it" language, while Python utterly rejects that and adopts the "there should be one, and preferably only one, obvious way to do it" philosophy.

[1]: Obviously this is a very slap-dash comparison which isn't meant to be taken 100% at face value and is merely meant as a way to help illuminate the ideological differences between Ruby and Python, it's not an invitation to start a flame war.

If you want a better java look at c#, its statically typed with minor type inference but it has some support for dynamic types(http://msdn.microsoft.com/en-us/library/dd264736.aspx).

Neither python nor ruby have any special support for pure functions, I suppose you could use some sort of decorator marking pure functions which one of those python subset compilers(or pypy) could use for performance optimization but I'm not aware of anything like this happening right now.

Also I don't think ruby supports list comprehensions it supports oo styled higher order functions, c# without the special syntax does the same thing. You may argue this is just a syntax but list comprehensions are just syntax that , you can rewrite them with nested for loops and appends(yields in the case of generator expressions)

I think in many although not all ways ruby is more of a smalltalk(but more practical).

Python doesn't exactly have an exact idealogical parent, although it has ABC as a historical parent(http://en.wikipedia.org/wiki/ABC_%28programming_language%29). Python outside of core imperative freeform do your own thing, want to write a oo based solution sure, want to write large imperative functions, go ahead, want to use modules to organize those go ahead. Want to use named function arguments or kwargs or objects or dictionary args go ahead. You can choose to use itertools, or your own yielding functions, or generator expressions sure.

I should point out that the first public version of Python was released almost 5 years before Java. So if anything Java is a poor Python, although I really don't like that comparison at all, as Python is not mandatory-OOP.

The biggest difference is the communities surrounding each, and the impression each leaves on people.

When I think of "Python", I think of a mature, helpful, experienced, talented, well-educated community. I can generally trust their advice, I can trust their code, and I can trust their technical decisions. It feels like collaboration is important and encouraged.

The Ruby community, whether this is deserved or not, leaves a very different impression. Anything good is quickly and heavily overshadowed by the unnecessary and petty drama, the egos, the fixation on worshiping certain figures in the community (DHH, Zed, why the lucky stiff), poor technical decisions, inexperience, repeated displays of very immature conference behavior, and so forth.

In can reflect very poorly upon a language when the community is generally toxic, like in the case of Ruby, or very positively when the community is generally superb, like in the case of Python. This is true even when the languages themselves are rather similar, from a technical perspective.

I think this is a little unfair - you do prefix your thoughts on the Ruby community with 'whether this is deserved or not', but then treat your perception of the community as fact.

I'm a Rubyist, and I've found that the vast majority of the community, events, interactions, etc are smart and civil. Yes, the Ruby community does have a bit of a publicity problem, but that's just the noisy/stupid minority.

Perhaps this is a common issue more broadly. (Are all PHP developers stupid? Are all lawyers money-hungry scum? Do politicians have no regard for intelligent discourse?) Our media (whether that be mainstream or Twitter and HN) is great at highlighting the controversy, but not a good source for a deeper understanding of the lay of the land.

As a former Python dev, I find the Ruby community to be just as positive an experience as the Python. Different, but just as positive.

Any community will have stratas of personality types that exist in various proportions:

* The loudmouth alpha types (DHH, Zed)

* The playful jesters (_why, Tom Preston-Warner) who are often evangelists

* The sharp-minded, code-focusing engineer types code (lots!)

* The newbies (lots, too!)

The Ruby community has been perceived as blighted with in-fighting, but it is, in my opinion, rather a case of certain people, the first type, trying to be public leaders, and failing at it. Those big sounds are just ill-considered publicity stunts. It's clear that DHH wants to be the Linus Torvalds of the Ruby community, blasting his way through perceived idiocy with profanity-filled speeches appealing to common sense and good engineering. Zed seems to want to be Jamie Zawinsky. Leadership does not come from being loud.

Ruby has its share of the playful and weird. Sometimes they give the impression of hyping something, because they bring with them their rosy-tinted version of the world where everything is fun and great. Sometimes they come across as glib and obnoxious because, well, they are, a bit. Overall I think they are an asset.

These two types are the people you encounter if you follow blogs and tweets, precisely because those two personality types depend on publicity. The Ruby community will certainly seem overrepresented by idiots if you go that route. But if you go on the Ruby mailing list you will see a different community, one that looks more like the Python people. Matz and many other core devs are conservative, highly technical, mature, and very helpful. There are also many low-visibility sub-communities that are very professional. My local Ruby meetup community in Oslo [1] is a wonderful bunch of highly technical, development-focused people who have none of the negative traits you describe. And if you go back to the question of what a community is supposed to provide -- help, insight, direction, ideas -- there are tons of great people.

That said, do I think the proportion of highly-skilled, high-technical is somewhat smaller in the Ruby community than the Python community? I do. Python has gained acceptance in more conservative, engineering/science/maths-oriented environments where Ruby has not yet reached, partly because of tools like SciPy. In fact, my feeling is that Python seems generally to attract a higher proportion of "engineer types" who are attracted by Python's rigidity (one way of doing things, etc.), compared to Ruby's often extreme malleability and laxness. This also means that the Ruby community is potentially missing out on some hard-core devs, and without support from the engineering/science/maths sphere it's never going to get things like SciPy.

And as for the newbies, Ruby has perhaps a bigger than usual share of inexperienced devs who are pollute the library space with lower-quality code. I blame this on the fact that Ruby is so simple to learn and has attacted many people through Rails, and this gives some devs a false feeling of confidence. I have had my share of time spent wading through other people's bug-ridden, ill-architected Ruby gems, but then if anything it's taught me to be careful.

[1] http://irb.no/

How many years ago did Zed quit Ruby for Python? How many years ago did why disappear? And that leaves DHH, who almost no one "worships" (most of the time people just get angry at him over CoffeeScript or something equally trivial).

I think that ruby, perl, python and javascript are similar only in purely theoretical way.

Python - is "executable pseudoscript". It does not have ruby elegance, perl "worse is better", javascript ... minimalism(?)

I'm using python for prototyping. As communication tool.

I can describe all python scetches to every programmer, be it javer, c-sharper, C-developer or SQL-er.

Can I use perl/ruby/CSharp/Java/F#/Haskel?

Answer is NO.

Perl: sigils, regexp everywhere (when it not needed), parameters passing, "use strict", strange OOP - all those features makes it impossible for prototyping.

Ruby: it's the same as for perl. It looks more pleasant to eyes but it is no way "pseudocode" that everybody can read.

C#/Java - prototyping is a joke. And I can't use sharp-code for javer and otherway.

F# - F# is looking a lot like "pseudo-script". But the main strength - type system is not helping in prototyping.

LISPs - I think that LISPs are good for prototyping. The only problem - they are LISPs.

> Perl: sigils, regexp everywhere (when it not needed), parameters passing, "use strict", strange OOP - all those features makes it impossible for prototyping.

> Ruby: it's the same as for perl

Nothing you said about Perl can be applied to Ruby.

"The same" means "ruby as pseudocode is the same as perl".

You need to explain that 0 is True.

You need to explain blocks, (int_number).times and other cute things.

And I heard a lot of complains for whitespace, but begin-end is more irritable for many.

> You need to explain that 0 is True.

Easy: it's not C.

The idea that zero is false only makes sense if you're trying to code very close to the metal. To everyone else it's baffling.

> "The same" means "ruby as pseudocode is the same as perl".

Right, except none of the reasons you gave for why perl is a poor pseudocode apply to Ruby, so you need to make that point yourself.

> You need to explain that 0 is True.

The truth values of integers don't usually come up in pseudocode.

> You need to explain blocks, (int_number).times and other cute things

I agree that the concept of passing around a block of code is hard to implement in less expressive languages, though cases like "each" and "map" can be simply translated to for loops. You could make the same criticism about Python's lambdas or list comprehensions.

n.times is perfectly useful pseudocode, though. Think of it as a shorthand for "for(i = 0, i < n; i++)".

2.0 on the 20th. Happy 20th!

Ruby is now also 20 years old. https://twitter.com/yukihiro_matz/status/305334327938519040

That's what I meant - 20th birthday

I've been waiting for native keyword arguments for years. A great addition that should make code more maintainable.

I guess, Rubinius is no longer relevant? I remember it was a very promising project back in 2008.

Evan Phoenix (the creator) left in 2012 to work for LivingSocial. EngineYard, his former employer, had been funding work on it last I heard, but there haven't been any releases since 2011.

http://blog.fallingsnow.net/2012/03/28/a-new-door-opens/

Only in the same sense that there haven't been any Arch releases...

EDIT: Just checked. If you `rvm install rbx`, you get code written today.

> there haven't been any releases since 2011.

Every commit is a release of rbx. Yay continuous integration!

That said, there hasn't been a numbered release in a while, through there will be a 2.0.

Yes, sorry for not being clearer. I'm basing the "there hasn't been a release since 2011" comment off of the Rubinius homepage, where the last numbered release is 1.2.4.

The Rubinius 2.0 preview release came out in June 2011: http://rubini.us/2011/06/07/inside-rubinius-20-preview/

https://github.com/rubinius/rubinius

It's very relevant, and very active.

I really wish Rubinius has become Ruby 2.0. Making Ruby more Ruby and less C opens lots of doors.

Congrats Ruby team - really well done. 20 great years.

Is ruby 2.x faster than 1.9.x. Any benchmarking data?

Yes, there are performance increases. Sasada-san gave a good talk at RubyConf this year on 2.0.0's internals and performance enhancements: http://www.confreaks.com/videos/1272-rubyconf2012-implementa...

My favorite new feature. Keywords arguments. As a Python convert, I really missed those.

Just curious: what made you switch?

I totally agree about refinements being a terrible idea. Brian Ford (of Rubinous) makes an excellent argument: http://www.youtube.com/watch?v=BagNfTbXn3w.

What is the best way to let Ruby team know that refinements are a bad idea?

> What is the best way to let Ruby team know that refinements are a bad idea?

Get involved in the discussions on ruby-core.

Serious question - should I learn Ruby?

I spent a little time looking at Ruby in the past. It seems like a nicely designed, clean language. However, it seems to me that it lost to Python in many domains. In addition, I've heard stories about Ruby having performance problems. For example, I heard Twitter rewrote their backend in Java/Scala because Ruby didn't perform well enough.

Recently I was at a Cloud Computing symposium thing attended by academics and industrial developers. No-one in the room was using Ruby for development anymore. Has it died? Is there any point learning it?

Learn what you want to learn, because your tools will change. Many Ruby programmers came to Ruby because of Rails. I'm part of the camp that stuck around because of JRuby for a while, but nowadays I find that I write very little Ruby and a lot more Python.

Don't worry too much about what you hear about performance. If you are building a Twitter, then yes, it might matter what language you're learning. Ruby, Python, and PHP tend to be in the same ballpark in terms of performance, with each having their own warts.

As of late, I've been most interested in golang.org. You can learn the basics in an afternoon at tour.golang.org.

Cool, thanks. Actually, Go was an alternative I was considering for my next language. More worthy than Ruby? Is it a possible Python replacement?

I wonder, is asynchronous exception handling going to make exceptions useful in evented/fibered code? Because right now, the ability of your stack frame to unpredictable blow up is a complete nuisance.

Congrats, Ruby Team. Always good to see a new release. Onward and forward.

I was stuck on this for a few hours, so hopefully this might help someone. If you are install ruby 2.0.0 with rvm, make sure you do rvm get head before doing rvm install 2.0.0 or rvm reinstall 2.0.0

I like Ruby but keywords arguments are the solution to a problem which shouldn't exist in the first place. Namely functions like..

myFunction(something, 23,23,100, somethingElse, true)

People should write smaller, more specialized functions instead (less arguments). That makes software both: more efficient and more maintainable.

If you start thinking: "Damn I wish I had keyword arguments to make this function call more comprehensible!" .. the problem is elsewhere.

100% disagree. For some use cases they are very useful. Like, imagine a function that generates an HTML snippet, and can optionally assign some specific class names/ids to some of the elements.

As much as many people seem to hate the way Objective-C does things, I really like how it intersperses the arguments in the function name. It makes it so easy to identify parameters.

Most languages:

  someObject.throwProduce(apple, myEnemy, 14, 17);

Objective-C:

  [someObject throwProduce:apple at:myEnemy withForceInN:14.0 maxDisanceInM:17.0];

As long as you name the function appropriately, it's clear what each parameter does without having to look up the name. Many people complain about the long names (in this case throwProduce:at:withForceInN:maxDistanceInM:thenWaitInMS:), but it avoids the situation you have in other languages where there are 4 functions with the same name but different signatures. In Obj-C the naming conventions discourage such ambiguity and encourage self-documenting names.

Just submitted a pull request to Homebrew to have this added. Can't wait :-)

I'd definitely look at rbenv. Combined with it's plugin ruby-install, you've got a pretty simple and powerful alternative to rvm. I use it exclusively.

rbenv is definitely better than rvm, but if you use the same ruby version between all your projects, a single version of ruby installed through homebrew is a much better way to go.

Does anyone here have a link to the new rubydocs for this?

We need tutorials. Videocasts! Please.

Nice. Time to use to_hash.

Still waiting for Ruby 2.0 Benchmarks

Congrats! Great works

ruby pls

Ruby rocks my socks.

Today, I'll lose at least 50 karma points, but it's worth:

Why people still use Ruby?

1. Because they get dream day rates for maintaining rusty slow legacy systems

2. Because they do not want to learn new languages and can stay in their comfort zone

3. Because they think it's still 2005 and nobody cares about slow server response times

And now Ruby lovers, click on downvote or give your reasons why you still use Ruby.

It's fun, it's clean, it's simple, and it works.

I use Ruby some, but I'm not sure I'd describe it as clean exactly. I've used Python a bit recently and was struck by just how clean it seemed. (I'm not sure Python has anything that quite replaces blocks, though. I don't claim Python's all better than Ruby.)

Cleanliness is subjective, but:

* Everything is an object, without exception.

* The object model is pleasingly orthogonal and its behaviour is easy to understand and predict once you know how it works.

* The syntax is high on alphanumerics and low on punctuation.

* Most of the core library method names strike a good balance between brevity and clarity.

* `Enumerable` is simple and powerful.

Amusingly, you could be talking about Ruby or Python on all of these points (if you swap swap "Enumerable" for "the iterator protocol").

Arguably so. :)

In my opinion Ruby pips Python to the post (however slightly) in each respect, but it's clearly a question of taste.

I am a pythonista by hobby... and I've seen many times in these too many ruby / python comparison, that only in ruby "Everything is an object, without exception."

but... I cannot find a "thing" that isn't an object, in python neither... care to tell me, or point to a link regarding to, what is the difference in this context between the two languages? Just an example or something like that. Thanks.

Trying to guess how Python works is quite hard if you're used to Ruby and other languages closer to Java.

As I don't know much Python myself, it's hard to tell where Python fails the "everything is an Object" check. But in Python some legacy calls were more procedural than OO, like "len(o)" rather than "o.len". I think eventually Python got to support both approaches.

I think Ruby is all objects even in its C abstractions. In Ruby, people create classes and so on in the RubyC abstractions that are visible to the Ruby language too. Not sure how Python does those.

I know Python has reference counting for Garbage Collection, so there are differences to their approaches in that regard and more.

Like Guido Van Rossum said, from 10,000 feet both Ruby and Python are more alike than different. He was saying that people should appreciate them more even if they belong to the community of the other one. That the real enemy is languages like Java that switch around the priority by making code that compilers prefer rather than programmers prefer.

I think Python has a Functions legacy that could not be as OO as they would be in Ruby.

Right now I'm more "in love" with Dart than with Ruby. Ruby was my first real love though.

Just as note: I don't really would call "len(o)" a "legacy call", as in "something it's here just for backward compatibility, but it's ugly and please don't use it".

It's more "the good way to do it" :D

len() is a perfect example of the duck typing and the "protocol-based" philosophy of python: its implementation it's something like

    def len(object):
        return object.__len__()

as in "just return the result of invoking the object method called __len__".

this lets you just call len() on every "len-able" object. They can be list, dict, custom objects... instead of the need to, I don't know, implements an explicit interface, or define a "getLength()", "size()", "length()", "length" (just an attribute, not a function to call), you can just define a "magic" (as in "normally you don't need to call this directly") method called __len__.

you can create your "not really a container, but it has a length!" object as something like

    >>> class C:
    ...     def __len__(self):
    ...         return 42
    ...
    >>> len(C())
    42

As indirect effect, it enables you to go on the functional-style approach... a simple

   map(len, list_of_lists)

it's more readable than

   map(lambda l: l.__len__(), list_of_lists)

(probably [len(l) for l in list_of_lists] it's more readable, but bear with me...)

I'm not really sure about the "ruby C abstractions": do you refer to the use of "object-like" structs used in the C sources of the "ruby MRI" implementation of "ruby-the-language"?

regarding the GC... I don't know, but why is the kind of the GC used by an implementation of the language (or the complete lack of a GC) relevant to the "everything is an object"?

just to be clear, I don't dislike ruby :) it's just that I don't find the "everything is an object" a way to discriminate between ruby and python.

You see, you wrote a bunch about how len is so cool in Python. But in the face of dynamic typing and polymorphism I didn't expect it to be any different really. Languages like Go that are statically typed make more of an issue about interfaces. Even in Dart they dropped explicit Interface usage in favor of implicit interfaces, considering that Dart is more explicit about matters than Ruby is.

Switching those function calls around reminds me of Delphi. When I first learned about Python, those calls reminded me of Delphi which I had used more. But once I learned Java, my frame of mind went from function(object) to object.function. With Ruby I found it quite intuitive. Now all languages work better if they approach things the way Java and Ruby do because of familiarity. That's why I like Dart for what it's worth.

Regarding C extensions of Ruby, they are like OO in C. Not sure how Python does it by default. But in Ruby all C extensions have a OO flavor. The first major book about Ruby writes about them: http://www.ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.h...

I think if you're counting references in the GC perhaps your C extensions are not very OO yet. In Ruby as in Java, the GC is an abstraction over reference counting. I think reference counting is often said to lead to more predictable performance at the cost of increasing the maintenance burden.

So again, not sure where Python is not "Objects all the way down." But Ruby has had the OO philosophy from early on. I think the Ruby OO approach started with the OO of the C extensions and went from there. Unlike Python that had a stronger procedural influence. The gap has closed since, but in Python a class is not written like this yet:

  class InRuby
  def aMethod
  end
  end

  class InDart {
  aMethod() {}
  }

I don't get the last part...

in python a class is written as

    class InPython:
       def aMethod(self):
           pass

but... what I'm missing? I can't follow the reasoning...

regarding the C extensions... I didn't really needed to write one, but from http://docs.python.org/3/extending/extending.html#a-simple-e... I see

    static PyObject * 
    spam_system(PyObject *self, PyObject *args)
    ...

so I assume also on C level the python objects are mapped on some structs in OO fashion...

I honestly have no idea on how is (or if it has some meaning) to extend python in rpython on pypy, but in this case I assume there are some objects involved :D

Exactly. In Python you still pass "self" to the method. In Ruby and Dart it's not needed.

In Python I've seen Python users discourage the use of classes. I haven't seen the same distrust of classes in Ruby for instance. It's as though Python has unresolved OO issues. Python could take pride in being "multi-paradigm", whereas languages like Ruby and Dart could take pride in being more OO.

Regarding the C extensions of Ruby, I think the bottomline is that from int, to booleans, to null, to classes, everything is considered OO even in the C code. So common functions can be applied to them even from C, say like Polymorphism would in other languages. From the primitives on up everything is like a high level Ruby. As Python is more "multi-paradigm" perhaps some of its C extension features aren't as OO as Ruby's are.

Funny though that those C extensions that make Python and Ruby so popular end up making other implementations of those languages that target other runtimes incompatible as they don't have access to those C extensions. So even in that regard they are similar.

Say we can't find anywhere in Python where Objects don't exist. Then welcome on board of true OO. Now show OO some love and stop discouraging the using of classes. Maybe drop the "multi-paradigm" approach. I know though that like JavaScript, sometimes you have to live with the shortcomings of the programming language in its support of OO. So while JavaScript could be said to have Objects everywhere, and it truly does, writing classes in JavaScript is not a settled issue. That's why I like Dart instead:

  class A {
    var aList = ['a', 'aa'];
    get length => aList.length; 
  }
  
  class B {
    var aList = ['b', 'bb', 'bbb'];
    get length => aList.length; 
  }
  
  class C extends A {
    var aList = ['c', 'cc', 'ccc', 'cccc'];
  }
  
  printIt(o) {
    print("${o.aList}: ${o.length}");
  }
  
  void main() {
    printIt(new A());
    printIt(new B());
    printIt(new C());
  }

Result of running it:

  [a, aa]: 2
  [b, bb, bbb]: 3
  [c, cc, ccc, cccc]: 4

>>Say we can't find anywhere in Python where Objects don't exist.

You're correct - we can't find a place in Python where Objects don't exist. Python and Ruby are exactly same in this.

>>Then welcome on board of true OO. Now show OO some love and stop discouraging the using of classes.

What do you mean by true OO?

It does not matter if you "love" objects or not. You can't write in python without OO. Every python module is an object, defs and vars - members of object. (Even classes and other modules are members of module object).

Or, instead of having the convention that objects with a length implement __len__, you could have the convention where they just implement len and you could just call obj.len.

In java the arrays objects expose a public int attribute called .length. The strings also expose a .length attribute, but it's a method. If, for some reason, you need to know how many elements are in enum, you need to call NameOfTheEnum.values().length. If you have a Collection (a Map, a List...), you need to call .size(). ...

Yeah. You are right about the fact that a possible "convention" would be to call .len, not .__len__ but you are forgetting 20+ years of backward compatibility.

I don't know when len() was introduced, and I'm not sure it's initial implementation was a simple "return object.__len__()" (or an equivalent...). What I know is that an explicit len function helped to hide the eventually different implementation details, and allowed the developers of the containers go crazy with attributes.

Moreover, with a len(obj) function and a obj.len() "public" method, you have two ways to do it.

I'm not sure why Python has to be backwards compatible with Java, given that Python is a totally different language released four years before Java.

I wasn't trying to compare Ruby and Python (I'm not a big Python user); I was just explaining why I said Ruby was "clean". As simonw observed, all of these points arguably apply to Python too.

Because it makes me happy.

I like writing Ruby and the speed isn't at the point where it makes a difference. A much better argument would be pointing out the tens of serious security vulnerabilities this year. :)

So, which Ruby security vulnerabilities were announced in 2013? I'll settle for ten instead of "tens".

People still write PHP and it is even slower. And who writes web services in pure Ruby? The response speed depends very little on the language used.

Is that actually true that PHP is slower? Say something like Symphony2 vs rails for a reasonably complicated app. Is there much out there in terms of benchmarks?

(I think we are both coming from that it really doesn't matter most of the time side but would be interesting to know if PHP is actually slower).

I don't know about Rails, but as a Symfony2 user, it's actually a bit on the slower side compared to other PHP frameworks.

But ~300ms server response times is nothing if your end user has to wait 5-6 seconds for the page to render due to suboptimal frontend code. Plus, throw in varnish/nginx microcaching and requests drop to ~10ms regardless of your framework.

> But ~300ms server response times is nothing if your end user has to wait 5-6 seconds for the page to render due to suboptimal frontend code.

True for a single request, but once you start getting lots of concurrent requests all those ~300ms server response times start adding up quite quickly.

When Twitter started out, their use of ROR wasn't a problem. Once the service started to become popular, however, it was.

> Is that actually true that PHP is slower?

Yes, the VM itself is not fast. However, a lot of it is just a thin shim over a C call, so whether you're going to be bottlenecked by it is going to depend on what you're doing.

Let me guess.. Node/Clojure/hip-language-du-jour-nobody-uses brogrammer?

Disclaimer: I am not a Ruby programmer.

Its language semantics are a sweet spot for me.

And in my kind of web applications I handle massive load via HTTP Caching, leaving your "fast" language without cache-aware architecture far behind, thank you very much.

And then then the fast lanugage implements caching.. Your first point is valid

The language does not implement caching. Your application architecture needs to take server caching into account.

And in my experience, devs who focus so much on the "fast language" part, do so, because they don't actually know much about caching. And no, this statement is not universally qualified.

With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy.

However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.

I don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.

You don't implement HTTP caching, except in very specific cases.

You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.

Of course "you don't implement caching". I think it was clear that I was talking about designing a cache-aware application.

Cf. http://www.mnot.net/cache_docs/.

Yes, and I was talking about implementing caching of components used to compose the pages and API responses, not a full HTTP cache tier that has to be placed in front of your application.

Okay, then I misunderstood where you were getting at. My fault.

Don't feed the troll, please...

I downvoted you just because of your anarchical attitude ... That is not the right way to start a healthy/useful discussion.

> That is not the right way to start a healthy/useful discussion.

Maybe you are right but I am just fed up that on HN the forefront of new tech still such old slow technology gets upvoted on a regular base mostly by people fearing their go to tech is vanishing away. Ruby/DHH/its entire opinionated ecosystem is so 2005.

> is so 2005

So you have no actual quantifiable arguments and resort to this and ad hominem attacks on people that use a programming language? Not the best way to make your case.

And you deserve to lose those 50 points. Why do people still write silly comments like this?

1. Probably 75% of new startups are using rails, and rightly so. You'd need a good reason not to use it. "Rusty slow legacy systems" - what nonsense.

2. If there was a better language, they'd probably learn it? Or are you trying to insinuate Ruby programmers are dumb/lazy?

3. If you are blaming your slow web page on Ruby, you're doing it wrong.

> 1. Probably 75% of new startups are using rails, and rightly so. You'd need a good reason not to use it. "Rusty slow legacy systems" - what nonsense.

75%? Evidence? You are the one who is talking nonsense, sorry to be direct and getting on Reddit level but you started.

> 2. If there was a better language, they'd probably learn it? Or are you trying to insinuate Ruby programmers are dumb/lazy?

Do I really have to tell you? Instead of doing some research Rubyists still defend their old tech (like you do now).

> 3. If you are blaming your slow web page on Ruby, you're doing it wrong.

Yes you are right, and now get back in your comfort zone and code some slow web services.

> 75%? Evidence?

None really, just the startups at an incubator-type place near me. Might not be 75% but it's certainly a big chunk and probably the majority.

So no evidence whatsoever.

No java, JavaScript, python, php, perl, c++, c#, erlang?

My hunch is that it's pretty rare to see a new startup using Perl, Erlang, C++ or even Java.

It depends a lot on the business and the sector. Serious startups in fields like biotech, nanotech and finance are still very commonly using languages like C, C++, Java and F# for new projects.

These are companies creating software that'll likely still be around and in use 10 or 20 years from now, rather than web startups who will likely not survive more than a couple of years, or will rewrite their software time and time again using whatever the current over-hyped language/platform of the day is.

This is one: http://news.ycombinator.com/item?id=4461427

Also they don't get the attention the hot languages get.

However there are some Perl startups, for eg: Lokku, Blekko, Moonfruit, DuckDuckGo, CareerJet & Adzuna

Firstly (Disclaimer) I am a Rails developer, I choose to be one right now, until (if) I find that my efforts are better spent elsewhere.

I agree with tferris to some extent. Those arguments are nonsensical to say the least.

This might be a feeling, I am not one to shout random feeling-based percentages, but I feel that people, in general, not just HN, don't realise that you can just claim things in this way. 75%? Where does that come from?

Also, the second argument is complete rubbish. By this logic anything that the masses do is better? So Earth was flat at some point in time? And yes, I think that people ARE lazy, as we should be, why use a framework otherwise? But some people are just stuck in the before mentioned comfort zone. Evidence is the popularity of Rails clones in PHP (or at least attempts at). Why not just learn Ruby and use Rails? => Fear of learning new programming languages and being new at something?

Third argument is right to a certain extent. If you need to invest a lot of trouble to make some slow code (which Ruby tends to be) faster, at what point do you choose to just use something faster? Where is the line; break even point?

I use Ruby at the moment too, but you have to remain critical and even more so, you need to reflect on your own ways of reasoning.

Well you should use a framework not because you are lazy but because there are a million other actually important things you should be doing than implementing state for HTTP for the billionth time.

Potato potato.

You are a 'glass-half-empty' interpreter of the word 'lazy'.

Easy syntax, DRY, etc. are things that are good because they limit you to waste time on trivial things, like you said. They stop you from reinventing the wheel.

I call that (positive) laziness. You can call it whatever you want of course. It still boils down to the same thing.

I have worked at places where programmers were willing to write thousands of lines of code, often copy-pasting big chunks and just replacing a few variable names. Needless to say, I didn't want to work there for very long. There is often no way to convince those kinds of programmers to stop and think about logic or technical design. They feel that they could just as easily write a few hundred lines again and again. Me, and my others, feel that you shouldn't repeat yourself in code and should limit your day-to-day efforts by writing reusable code, etc, etc. I don't need to tell you of course.

Do you mean PHP languague ?

> By this logic anything that the masses do is better?

Yeah, I could have worded that better. The OP said:

  Why people still use Ruby?
  2. Because they do not want to learn new languages and can stay in their comfort zone

Which implies that a reason people are "still" using ruby is that they are too lazy to switch to one of the new, "better" languages or frameworks. I was just trying to point out, maybe they haven't identified that there's a better language or framework yet? I am not aware of any obviously superior alternative and if I found one, of course I'd start learning about it.

75% was a wild-ass guess which I nonetheless believe is pretty much right. But maybe it's 50%. Who knows. The point was, rails devs are not solely working to maintain "rusty slow legacy systems".

> I am a Rails developer, I choose to be one right now, until (if) I find that my efforts are better spent elsewhere.

Couldn't have said it better myself.

Having spent a good year at the 2012 batch at the 500 Startups office, I can safely say that the majority (>60%) of the guys I spoke with there were working off some sort of rails stack.

I dont know about that 75%. Considering that more and more people are using Nodejs. Just take a look at some of the companies using Express. http://expressjs.com/applications.html

Why is this post at the top? It's nothing but flame bait. It consists entirely of feces-slinging, and not a single substantive topic is addressed.

> It's nothing but flame bait

Why? I am damn serious about every point: Ruby/its entire ecosystem/Rails/DHH is outdated/becoming obsolete/so 2005.

Repeating "x is so 2005" is not a discussion point.

Your original post, and every one since (including the multiple sets of edits you apply to each), consist of nothing but a daisy chain of mud slinging and ad-hominem attacks directed at other commenters.

You're a troll, plain and simple. Sorry for feeding you, but I simply think it's sad this unproductive rant has completely derailed the entire discussion here.

Repeating "x is so 2005" is not a discussion point.

I agree, just because something has been around a long time e.g. Unix/Linux doesn't mean it's bad.

If I had a buck for every time I heard a Rubyist say "Java is so 90's" ...

And you backed it up with no facts what so ever.

I think asking the question why people use it is a good topic, it could have been asked in a better way

I downvoted you for writing "loose" instead of "lose".

Thanks, corrected.

Great points. Speed and newness are paramount!

This is exactly why the most accomplished hackers write their web apps in SSE4.2 machine code.

Awesome idea ;-)

You're not having your app baked into ASICs?

It is one of the most active eco-system out there, and gems are a breeze to install.

Ruby itself is quite flexible and easy to use although it does have quirks.

But yes, ruby is hellishly slow. I have not enough experience to speak about the legacy systems, though it would interest me to know about that. You do hear a lot of stories about switching from Ruby to Scala/Java/Clojure.

Should we learn some 'new' and 'fast' language, then code slow service?

Now tell me, did you initially learn to code just because you liked fast things? There is more to it.. it's sad when these "once-IT-lovers" forget about this part completely.

I believe that Ruby was born in the first place with a kind of a sentiment of not wanting at all to become the speed optimization guy if that ever means sacrificing the part in itself that allows for so much freedom and creativity! And I guess this is exactly how the community around it feels it.

You get the good milliseconds stats, plus money.

A Rubyist might respond with a bunch of more ms. here and there(for now); he gets the same money; he has much more fun.

Is it so hard to understand ?

Do you still enjoy programming like you did in the first days? If not, take a look at Ruby, seriously :)

Probably, better Ruby performance will come with time, but if Ruby will fail in the long term, then it will happen just because of a new more performant, but equally (or more) fun/smart language.

In conclusion I think that Ruby has the merit of having woken up the feeling that programming can always be as fun as the first days and.. that it doesn't have to transform you into a sad, dissociative geeky looking person anymore.. :P

No offense intended!.. :)

I have quite a bit of Ruby for the server-side. But on the client-side I've been using Dart instead.

While Dart could be good for the server-side too, as it's VM will be as fast as any other dynamic language VM out there and the language is still quite cool, on the server-side we get to choose the tools more freely so there are many options.

Then again, why would people use Dart or Ruby on the server-side if they could use Go instead?

Go and languages like it are more lower level and sometimes more demanding, making mixing and matching while programming harder.

Mixing and matching is a way of programming for today rather than for the future. Say, dealing with the issues as they present themselves rather than trying to go around them. Say, dealing with the UI as they are popular rather than doing things in an unusual way while trying to guess the future.

I really liked watching an Intel guy say that if your approach to parallelism isn't about sharing the load to over a hundred threads, then forget about guessing the future.

For now as in the past, people have been successfully using threads for doing what they were originally meant for as Guido Van Rossum explained in a recent video. Threads were meant for concurrent I/O work. Now people want to push them to doing more parallelism. Not sure how we are going to get there.

Because like supporting many GUI front-ends has taught us, getting the most out of GUI often means that you need to target them on a one-to-one basis. Creating programs that support 1 thread or 100 threads from the same codebase will be quite a challenge going forward. Because if you want most performance from just 1 thread, it could be that the program needed to be written one way. Whereas to make it better for 100+ threads, it could need to be written a different way.

So, why would people write Ruby? Because it works. The Internet is unreliable anyways. Depending on a central server is too all-eggs-in-the-same-basket for the Internet.

Also Ruby is getting more stable. Depending on new tech can lead you to unstable nightmares.

If you were worried about bigger codebases and still wanted a language like Ruby, I'd first recommend Dart than Go. But for its current stability concerns. It will hit 1.0 soon though.

You might as well ask why people still use Java. Because it works for their purposes, is popular (i.e. has market demand), and there aren't enough perceived incentives to move to a newer/better language yet.

I'd very much like to learn the next great framework and its language - I just haven't been convinced by any of the front-runners quite yet (especially in terms of ecosystem resources). When that happens, you can bet many coders like me will jump on it. Till then we'll just continue to work on our Rails apps.

> why people still use Java

I am not into Java but I'd rather prefer using Java the next 10 years than Ruby 1 month. At least I get a perfect language implementation (the JVM) with Java.

> At least I get a perfect language implementation (the JVM) with Java.

I don't agree with you about the JVM, but you're clearly ignorant of Ruby if you're not aware that there's a Ruby implementation that runs on the JVM (JRuby).

You seem to think people should constantly jump ship and change languages/ecosystems. I used to do this, and the result is that you don't get results.

I still look at new developments, and toy with new technology and programming languages, but when I want to get shit done, I find there's little that defeats using plain "old" C, Ruby, Java or whatever else you would probably call outdated.

You don' know what you're talking about. I lead the web team for local.ch, we have 4mil unique clients a month and handle 10k requests per minute in peak traffic. Our site is developed in Ruby on Rails, with average response times from in the 150ms range. We replaced our legacy PHP system last year and will never look back. Ruby 2.0 will be our future, and I'm happy about that.

We're having millions of unique clients per month and our peak traffic is above 200k requests per minute. Ruby delivers, although you need to be very careful what you deploy to the main app codebase. Especially to realize the speed differences between stuff like uniq vs. uniq! or the cost of creating new objects. It's enormous with big traffic.

There are some things I wouldn't do with Ruby here. Like some concurrent background jobs; better solution would be Clojure, Erlang or any language where the concurrency constructs are better thought and easier to manage. Although we're having threaded Ruby running, it's not very elegant and you can do pretty nasty bugs in there.

that's about 3.3k requests per second. How many hosts is that spread across?

Maybe too many, I guess. Not giving any real numbers, but I suppose with JVM this could be much less. Oh hell, even with some refactoring here and there we reduced the overall CPU usage a lot. Like I said, with real traffic, the bang methods are a much better choice even though the functional programmer in me is against them.

Ruby lovers are all about "feelings" and "style", they don't care if their language of choice is objectively worse than, say, Python or Lua.

Ruby truly is the Apple of the programming world.

You're wrong. Do you know Ruby is the breed of so many developers (who has used other languages, too) ?. You should compare Ruby to open source philosophy, it's one of its implementation. Yes, if Ruby was dead, open source is dead too, i believe it !

> Ruby truly is the Apple of the programming world.

No fucking way.

I fought with Python for weeks before I picked up Ruby. It clicked perfectly and I've never had to fight with it.

I don't see how Python can be objectively better than Ruby.

I don't know enough about Lua to comment.

I really love the use of the word "objectively" in your sentence. It's totally irrelevant and has no ground in reality or the realm of logical reasoning. As such, it is in fact quite revealing of your true intent with this comment: riling people up and trolling.

Maybe you should think long and hard about why exactly Ruby (and Apple for that matter) makes you so mad that even though you don't use it or program with it, you have to come here on an article about a new release just to spit some venom even though the language itself doesn't impact your personal life in the slightest.

People program in what they know and what gets the job done in the most optimal way for them. Learning a new language without a good reason past certain users not liking it is silly.

Plenty of people criticize Notch for using Java in all of his games, but Notch gets things done. It's hard to ridicule someone making so many useful things (well you can, but most end up looking like jerks lacking tact). Might not be in the coolest or most efficient language, but the results speak for themselves.

People use x language because x gets things done for them, their business and it shows results. People that spend much of their day thinking about how they dislike a particular language and its users generally are not the ones being productive with their more enlightened language(s) of choice.

Yup, there's no reason why you can't be productive writing code in Java if if you're willing to get over the fact that you'll be writing more lines of code.

I've been implementing a compiler in Java (not my original decision, but I don't think it was a bad one) and, although its frustrating at times knowing that some list transformation would be a one-liner in other languages but five lines of Java, it hasn't actually proven to be a drag on productivity. You have automatic memory management, a reasonable selection of basic collections, a reasonable selection of abstraction mechanisms, the ability to implement things like immutable classes, etc, so there aren't any major obstacles to productivity.

A lot of times when writing new code I wish I had builtin tagged unions, since I have to do it manually with a class and an enum. But once I've actually implemented a tagged union, I don't find that future additions and maintenance work on the code actually take any extra time.

Tell me what you are so bitter about. How has ruby wronged you?

You have a valid question, you didn't have to ask it so sneeringly.

I am a fan of Ruby in big part because of how it handles objects. In Ruby, everything is an object. Objects' only public interface is their methods. These methods don't require a pair of parenthesis to call them, so you can call them as you would access a public variable in other languages. You can easily set up getter/setter methods for an instance variable via an "attr_accessor :instance_variable" call within the class definition, or you can define its "instance_variable" and "instance_variable=" methods yourself.

This combination of things is I think Ruby's killer feature and makes for a very elegant workflow. You should give Ruby a chance :)

Reply on news.ycombinator.com