Ruby 2.0.0 Released • Hacker News Board

Re: Ruby 2.0.0 Released

#301

Post by jxf » Fri, Mar 01, 2013, 4:50 PM UTC

steveklabnik wrote: post #181

jxf wrote: post #16

Earlier quoted context omitted.

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/

> 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/

Re: Ruby 2.0.0 Released

#302

Post by draegtun » Wed, Mar 06, 2013, 9:29 AM UTC

simonw wrote: post #69

timc3 wrote: post #47

Earlier quoted context omitted.

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.

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

Re: Ruby 2.0.0 Released

#303

Post by anko » Thu, Mar 07, 2013, 7:13 AM UTC

gbog wrote: post #270

anko wrote: post #263

Earlier quoted context omitted.

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, whic…

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 renderin…

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.