Ruby 2.0.0 Released

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.

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.

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.