Ruby 2.0.0-preview1 is out | Hacker News Reader

Ruby 2.0.0-preview1 is out

blade.nagaokaut.ac.jp

115 pointstenderlove62 comments

I have a confession to make. I've been a Python (django+flask) guy for years, but I just recently jumped ship to Ruby and couldn't be happier. Within the last 60 days I've deployed 2 production websites, rebuilt my own personal blog, and am currently busting ass on my own project's API -- all of it in Rails. I still like Python, but I'm a HUGE fan of Ruby now. It's so much fun to write.

I'm excited to be a part of such an active community as well. It seems like every week there is an exciting event, release, or new project being announced.

Looking forward to building this locally, hopefully with these fast require patches applied: http://bugs.ruby-lang.org/issues/7158

self.woohoo!

what are the differences that make it more fun?

That's actually a really, really long comment. A blog post is definitely due about it, because I feel like a hacker again. Before I was in this fog of not enjoying what I was doing and always being up against some mountain/molehill problem.

I am in the same boat as gp. rails has a lot of nice time savers, RVM is better than virtualenv, I like that in ruby you have more than one way to do things so you can write the way you feel most natural, ruby is more fun to program in for me(not a huge fan of the indentation now because I have had to reformat scripts to work correctly one too many times now). packaging in python is what pushed me over the edge though. It never felt like I could get anything installed nicely because the "best practice" for the packing managers were changing daily. rubygems is much nicer in that respect. I still like python but in the future I am going with ruby unless I have to use something else.

rbenv (https://github.com/sstephenson/rbenv) is better than RVM.

I used rbenv for a while but what killed it for me was the huge startup lag it adds to every invocation of ruby or any other bin installed via a gem. I was seeing delays of 4-5 sec which disappeared when I switched to RVM. The universe of tools and integration is also far better in RVM land (though this may have changed more recently).

I had this problem right when I started using rbenv. Eventually with some help I realized that just starting bash was slightly slow, and that all the various bash scripts that rbenv runs were compounding this for a 2+ second startup.

In my case, everything was fixed by moving the the things that only need to be run in login shells out of my ~/.bashrc (where they should have been in the first place).

See the bug I filed against rbenv at the time:

https://github.com/sstephenson/rbenv/issues/70

Since that time, I've been using rbenv exclusively (development and production) and it's been great.

quantify "better"

I won't quantify, but qualify: it works without a pile of hacks like bastardizing cd, which fails in various real-world scenarios.

What do they need to override cd for?

From the scripts/cd source [0]:

    # Source a .rvmrc file in a directory after changing to it, if it exists.  To
    # disable this feature, set rvm_project_rvmrc=0 in /etc/rvmrc or $HOME/.rvmrc

IMHO rvm is completely overkill and suffers from overengineering.

[0]: https://github.com/wayneeseguin/rvm/blob/master/scripts/cd

Most users don't care if rbenv is better than rvm since they do the same thing, and apparently, at least according to the other poster, rbenv is slow

> according to the other poster, rbenv is slow

Define slow:

    $ time /home/lloeki/.rbenv/versions/1.9.3-p286/bin/ruby -e 'exit'
    real	0m0.012s
    user	0m0.007s
    sys 	0m0.003s

    $ rbenv global
    1.9.3-p286

    $ time /home/lloeki/.rbenv/shims/ruby -e 'exit'
    real	0m0.055s
    user	0m0.027s
    sys 	0m0.007s

Hardly something to cry foul for. Your first significant require will blow that time by an order of magnitude.

And hardly surprising either since rbenv the alias calls rbenv the command, which sets a few env vars then calls rbenv-$1 (probably $1==exec), which calls rbenv-hooks $1 (probably a noop by default) then $1 + args. rbenv is seriously thin.

> huge startup lag it adds to every invocation of ruby or any other bin installed via a gem

Sounds more like bundler (maybe automatically started by ohmyzsh when just typing 'ruby' where you have a Gemfile):

    $ time bundle exec ruby -e 'exit'
    real	0m0.570s
    user	0m0.480s
    sys 	0m0.057s

or as mentioned, someone put too much stuff in his bashrc or something.

To paraphrase a coworker who also uses Ruby: Whenever I guess at how to do something new in Python, I'm usually wrong.

All those years you used to make fun of me.

Trust me I feel like a tool for being such a fanboy.

And now after just 60 days you are allready a fanboy of rails. You should overthink how you put your loyaltys.

Took me only 15 minutes to realize what I've been missing. ;)

> You should overthink how you put your loyaltys.

You should think harder about how you choose to phrase a sentence. "Overthink how you put your loyaltys"? C'mon.

I had exactly the same experience. Long time Python developer, and then got into Rails and haven't looked back. Really love the readability of the language.

I'm happy for you. Could you be more specific about how ruby (as a language) and rails (as a framework) are more fun to you coming from python and then django/flask respectively? Is it the language you like more? Or the rails community?

Anecdotally, I've gone in the exact opposite direction. I had been doing Ruby/Rails for 3 years up until about December of last year and switched to Python. I can't say I dislike Ruby for any reason, however, I just have no desire to write software with it anymore.

The detailed 2.0.0 features list is at https://bugs.ruby-lang.org/projects/ruby-trunk/roadmap#2.0.0 for those interested.

I'm surprised there's not more talk here about the interesting additional features, like Proc/Method#to_source

I can't think of a situation when I'd need a method like Proc/Method#to_source, especially in everyday Ruby usage. That's probably why it's not being talked about as much as some of the other new features.

I can't find any info on these method right now, but assuming they do the obvious, it's useful for all sorts of tooling and debugging situations. Situations you might not write the code for but almost certainly will use.

Has anyone done any performance testing on this yet? Just curious if the new bitmap GC is more efficient with memory and also if 2.0 is faster as it was promised.

Benchmarks don't mean much until it's released, if ever. But I was playing around with it, and it's hard not to get excited about performance!

      |  mem | time |
  p1  | -24% |  -3% |
  p2  |  -8% | -12% |
  p3  | -31% | -12% |
  avg | -21% |  -9% |

(over 1.9.3)

Those are a couple workers I fired up for an hour. p2 relies on a C library, which might account for the smaller drop in memory usage. CPU needs investigation.

The numbers are kinda useless, but look good anyway.

Is it just me or has the world moved on from Ruby? I'm seeing more companies and projects moving away from it than adopting it. It feels like Ruby had a nice shot at becoming a mainstream language thanks to Rails but it just ended up blowing up like a bubble.

Plenty of people still use it, but like anything "being cool" doesn't last for that long. Lots of people still use Perl, but it's not necessarily talked about as being "cool" for example.

It's just you! The Ruby community, especially the Rails portion, is undergoing a fantastic philosophical and tooling maturation, which is pushing its viability past its former fast-paced start-up confines and into a larger, but perhaps less sexy market. I'm not sure which companies and projects you're specifically referring to, but while we're throwing out anecdotes, it seems to me that companies "moving away" from Ruby are making pragmatic decisions in response to specific pain points, while keeping Ruby in place where it better solves other pain points. That's how it's supposed to work!

The latest weekend-long Rails Camp to be held here in Australia (in 2 weeks time) sold out within minutes, as it always has.

As a counterpoint, many people who attend spend their time at camp not doing Rails stuff.

I think it just became a mainstream language. Many shops use ruby now, but nobody really talks how they're "using" ruby because it isn't cool anymore. Kinda like in the 2000's when everyone was talking about how they were using Java and VCs would throw money in their face. It's rare to see a company these days to evangelize their use of Java.

These days people prefer talking about how they're using node.js or Go.

There are secret weapons other than Node.js or Go, which don't necessarily make you more productive like moving from Java to Ruby.

Any details or evidence to back this up? I see more and more job opps for people with Ruby skills: startups, BigCos, Gov, nonprofits, I know longtime java shops that are rewriting their apps in Ruby.

I have worked with Ruby professionally for 5 years. From my perspective there is more opportunity now then years back, more high quality code being written, more problems can be solved in less time, etc

This is still a very exciting place to be. I have found being good at Ruby has provided the highest ROI of my career.

It's still in heavy use. I think it has plateaued compared to some other technologies but it isn't declining at least. I say this as a publisher with fingers in the Ruby, JavaScript, and HTML5 pies (the latter two are growing more quickly but Ruby is far from dipping).

Man, my anecdotal evidence is completely opposite, and I've been comparing notes with (some good) recruiters and other contacts around town for the last couple of years. Rails hit an inflection point in that period where even enterprises are comfortable with it.

In DFW, traditionally a dense forest of Enterprisey .NET and J2EE projects, I've seen a LOT of new Rails gigs pop up. A number of startups (growing in this area), but also big companies like Raytheon. I had a long conversation with an Adobe recruiter last year about their Rails initiative, and unless someone can point me towards different information, is it not the case that most web startups default question now is -- "is there a good reason NOT to do this in Rails?"

Rails and Ruby right now feel like Java circa the early 00s or thereabouts, where JVM performance concerns/FUD had clearly been dealt with and pretty much everyone was on board.

My hunch is we may look back on the last couple of years as being a similar tipping point for Ruby/Rails.

I never got so many dev and CTO gigs/jobs proposals that now, and this for very different companies (startups, more classic companies etc).

If by world you mean trend-driven web dev blogosphere then yes, however that's sort of a risky thing to use as your sole input to reality.

I'm seeing settling happening (we don't need to build as many basic libraries as when rails was still in its infancy) but number of ruby users is growing steadily.

Ruby/Rails has practically become the poster child for every (modern) web hosting company. EngineYard, Heroku, DotCloud, ShellyCloud, 6Sync, Webbynode, Linode, Brightbox, and the list goes on.

Let's not forget the advancement of JRuby (JVM Ruby), Rubinius (LLVM Ruby), MacRuby (For Native OSX Desktop Apps), RubyMotion (For Native iOS Apps), mRuby (For Embedded Apps).

Not to mention the truck load of conferences every year, the new and existing, accessible and easy-to-use open source projects that are being released and updated frequently.

"Is it just me or has the world moved on from Ruby?".sub("from", "to")

We're doing our best. :)

"Named arguments" - what took you so long?! it always annoyed me that this is not always considered a standard language feature and added in from version 0.1 of any language, no need to hack around it by passing dicts/hashes around ...Python got this right long time ago ...it always amazes me that people never seem to care about this

The standard solution (using splat and passing a hash) was close enough to work. It's not named arguments, and it certainly has its pitfalls, but it was close enough for most things. So nobody obviously thought it was important enough to change before now.

There's a lot of languages that don't have named arguments so it's probably not that much of a deal either.

...but the perceived philosophy of Ruby is along the lines of "developer joy above anyth else" (above speed, above code readability etc.) and this is a 100% developer joy feature and it's been ignored time and time again (probably because people are too busy building cool stuff to have time to bitch about this but still...)

It is. And the feature hasn't really been ignored. The hash-syntax was amended so that passing arguments as hashes can be made to look more like named arguments [1]. It's still not named arguments, but about as good as you can make it while still remaining somewhat backwards compatible. So yes, it took a long while but no, the pain was not very great. I never really missed that.

[1]

Voice-of-Evening:~ fgilcher$ irb 1.9.3p125 :001 > def foo(args) 1.9.3p125 :002?> puts args.inspect 1.9.3p125 :003?> end => nil 1.9.3p125 :004 > foo bar: "baz", foo: "bar" {:bar=>"baz", :foo=>"bar"} => nil 1.9.3p125 :005 >

Any plans on when 2.0.0 will be the standard? When will it be released to the world and when will it be adopted by people?

It's scheduled for a Feb 2013 release, and adoption among Rails folks will likely depend on how painful it is to upgrade to from 1.9.3.

Handy-dandy one-liner to install it with rbenv (provided you have ruby-build installed).

curl https://raw.github.com/gist/3998200/a09c4eb21256ad17880f7d8d... | sh

That script could be a one-liner in and of itself.

Not sure if RVM typically supported the preview releases. It would be nice if it did though.

    rvm install ruby-2.0.0-preview1

in my case, i need to do

  rvm install ruby-2.0.0-preview1 --verify-downloads 1

rvm get head rvm install ruby-2.0.0-preview1

installed it for me, but rubygems install failed

honest question. for someone who already know scala and groovy (moving from java), what is the selling point of ruby? esp in regards to (1) its syntax (2) its library and ecosystem and (3) its performance

Ruby's a top ten language -- neither Scala nor Groovy are anywhere near it -- so the ecosystem's much bigger. If we need JVM libraries, we can use JRuby without changing any source.

Admittedly, Scala's performance is faster because it's statically compiled, while Groovy's syntax is more standard, i.e. closer to C/C++/Java/C#/Javascript/etc. So wrt (1), Groovy, (2), Ruby, and (3), Scala.

(1) Syntax wise Ruby is a lot easier and more expressive than Scala. IMHO I feel that Ruby is an OO language with some functional sprinkles while Scala is a functional language with OO sprinkles.

(2) Ruby has a great ecosystem if you are building web apps. It's also got a lot of testing libraries. :) But in seriousness the number of libraries in non web/tooling space is slowly increasing as faster Ruby implementations have become a focus point. Also JRuby allows you use the vast ecosystem of Java from within JRuby.

(3) Performance wise I'm pretty sure Scala will outperform Ruby. I don't think JRuby will be able to compete either. Charles Nutter, JRuby Core developer wrote this blog post which explains why Ruby is hard to optimize ― http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby...

Of course take everything I've said with a bag of salt! :)

adding answer to my own question: with Ruby(Motion) you can make native iOS apps, and it's 20% off http://news.ycombinator.com/item?id=4732827 (just saw it in frontpage)

Notable Features:

  - Named arguments
  - Multiple inheritance (traits)
  - Incremental performance improvements over 1.9's VM
  - Better compatibility with non-unix environments and small/constrained devices (embeddable)
  - Sandboxed VM's (VM per thread)

There is no multiple inheritance in ruby 2.0, there are mixins (like traits) tough, but they have being in ruby since I can remember.

Also, there won't be MVM (Sandboxed VMs) on this release.

Ruby 2.0 was (and hopefully still) earmarked to have traits which are an enhancement on mixins providing a much better & refined compositional implementation.

Thus it (should) allow you to do things like excluding or renaming methods/traits ala Perl roles - https://metacpan.org/module/Moose::Manual::Roles#METHOD-EXCL...

Refinements will be at the 2.0 release but I wouldn't call that feature "multiple inheritance".

Neither would I because refinements are something completely different to traits!

Refinements proposed in Ruby 2.0 allows you to localise monkey-patching much like you can do in Perl with dynamic scoping (for e.g.: http://news.ycombinator.com/item?id=1603321 | http://news.ycombinator.com/item?id=3455507). For further info on Ruby refinements see here: http://timelessrepo.com/refinements-in-ruby

Traits are an improvement to mixins. IIRC Matz gave a talk (RubyConf 2010?) where he describes the proposed traits implementation. Here's one set of slides (not Matz's talk) which also shows some traits examples - http://www.slideshare.net/fabiokung/ruby-20-to-infinity-and-...

Half of these are not in ruby 2

Reply on news.ycombinator.com