Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Work has started on Ruby 2.0

github.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Work has started on Ruby 2.0

#51

Post by nirvdrum »

compay wrote: post #46
nirvdrum wrote: post #44

Earlier quoted context omitted.

Most of the large apps in production I'm aware of have just stuck with 1.8. It's stable and fast.

For most of my apps it's "fast enough" too. But I definitely wouldn't call it "fast."

Fair enough. But I meant "fast" relative to Ruby 1.9.2, not "fast" relative to anything else. The "require" issue aside, REE beats out 1.9.2 pretty handily in a lot of real world situations. I've seen 1.9.2 win in microbenchmarks, but I haven't actually seen it perform better on a real app yet. Obvious selection bias there, but the point really being there's no compelling reason to upgrade.

Re: Work has started on Ruby 2.0

#52

Post by dextorious »

Argorak wrote: post #25
terhechte wrote: post #2

Let's hope it will gain more acceptance and usage than Python3. Do they intend major changes?

I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers. The Ruby community is used to ensuring compatibility between JRuby and MRI(1.8 and 1.9) for a long time now and Rubinius support is getting `en vogue`. Projects like Travis will ensure that testing on 2.0 is "just" anther field on the build matrix.

> I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers.

I don't see any fierce competition against implementations in Ruby. I see that in Javascript implementations (and in HTML engines), but not in Ruby.

I wish that was not the case, but for real competition to exist, and also be fierce, each implementation should push other implementations to go better, adopt its successful features, etc.

What I do see is just parallel development of different implementations.

Re: Work has started on Ruby 2.0

#53

Post by dextorious »

jnoller wrote: post #27
lloeki wrote: post #8

Earlier quoted context omitted.

From personal experience the community at large is eager to move to Python 3. It has more to do with tremendous inertia generated by critical components being tricky to port to Python 3. Usual suspects Django and Twisted come to mind. IIRC NumPy gained support only recently. The Wall of Shame gives a very partial overview of the situation: http://python3wos.appspot.com/ It does not help that useful stuff from 3.x get…

If you would like more resources than the FUD laden wall of shame, feel free to visit: http://getpython3.com/ The timeline for Python 3 adoption was always measured in years - not one, not two, but more. We're not a development team or group that cough up unicorns about how long adoption of a backwards incompatible version will take. Django has a Python 3 roadmap, as does twisted, as does PyPy, Numpy, etc. The PSF an…

> The timeline for Python 3 adoption was always measured in years - not one, not two, but more.

Already a lot of YEARS have passed, not one, not two, but more. We're even in 3.2 for heaven's sake.

> Django has a Python 3 roadmap

Yeah, has had one for years. How is that going?

> The reports of death are grossly overstated.

The reports of movement in this front are grossly overstated too.

Re: Work has started on Ruby 2.0

#54

Post by dextorious »

TylerE wrote: post #19
lloeki wrote: post #8

Earlier quoted context omitted.

From personal experience the community at large is eager to move to Python 3. It has more to do with tremendous inertia generated by critical components being tricky to port to Python 3. Usual suspects Django and Twisted come to mind. IIRC NumPy gained support only recently. The Wall of Shame gives a very partial overview of the situation: http://python3wos.appspot.com/ It does not help that useful stuff from 3.x get…

Really? It seems to me like a mostly small vocal group is pushing 3. Most people I talk to actually using it heavily in production are ambivalent or actively planning on staying on 2. Python 3 is exactly how not to do a major language change. They broke enough that porting isn't trivial, and for many programs there just isn't any benefit. Plus the performance noticeably regressed.

> Python 3 is exactly how not to do a major language change. They broke enough that porting isn't trivial, and for many programs there just isn't any benefit.

All of that would have been acceptable, if they also implemented some major language fixes and adding some cool new features. Better closure support comes to mind...

Re: Work has started on Ruby 2.0

#55

Post by evanphx »

regularfry wrote: post #33
Argorak wrote: post #20

Earlier quoted context omitted.

I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?

I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.

It's being worked on right now and the infrastructure for it already in place. It's a goal.

Re: Work has started on Ruby 2.0

#56

Post by msbarnett »

regularfry wrote: post #33
Argorak wrote: post #20

Earlier quoted context omitted.

I know that they are on a good track towards 1.9 support. My point still stands: they are not there yet. So, if you were an MRI developer: would you switch to an interpreter where would have to build that whole stuff from the last 3 years again?

I can imagine a world where Rubinius never gets 1.9 encoding support, and declares it a non-goal. It's not that outlandish.

Leaving aside the fact that encoding support is explicitly a goal, it would be an incredibly daft thing to do to decide that Rubinius was going to take a regressive, all-the-world-is-one-encoding point of view and break compatibility with much existing Ruby code.

Re: Work has started on Ruby 2.0

#57

Post by lobster_johnson »

compay wrote: post #30
lobster_johnson wrote: post #28

Earlier quoted context omitted.

Considering that Rubinius is still considerably slower than MRI 1.9, that would be a big step backwards. Sure, considering that 2.0 will take a while to complete, one could put everyone to work on improving Rubinius' performance; but that would draw manpower away from non-performance work.

Rubinius has a different performance profile from MRI. It's considerably faster at some things and slower at others.

Yes. Unfortunately, the balance seems heavily weighted toward the slow end of the curve, so that in practice it comes out slower than MRI.

It's not just for things like Rails apps that Ruby is typically used for, either. I frequently process data, such as large log files, and now and then I try out the different Ruby to see if things have gotten better. So far, 1.9 and JRuby are the winners.

(LuaJIT is typically 2-5 times faster than both, so these days I tend to write my scripts in Lua.)

Re: Work has started on Ruby 2.0

#58

Post by compay »

lobster_johnson wrote: post #57
compay wrote: post #30

Earlier quoted context omitted.

Rubinius has a different performance profile from MRI. It's considerably faster at some things and slower at others.

Yes. Unfortunately, the balance seems heavily weighted toward the slow end of the curve, so that in practice it comes out slower than MRI. It's not just for things like Rails apps that Ruby is typically used for, either. I frequently process data, such as large log files, and now and then I try out the different Ruby to see if things have gotten better. So far, 1.9 and JRuby are the winners. (LuaJIT is typically 2-5…

Yeah, I agree. Lua is actually my favorite language ahead of Ruby. I have F3 mapped in Vim to run my tests; one of my projects is an implementation of Haml in Lua, and even that runs all of its tests in a small fraction of a second. The more you work with Lua the harder it can be to go back to Ruby sometimes.

Re: Work has started on Ruby 2.0

#59

Post by lobster_johnson »

Xylakant wrote: post #49
compay wrote: post #41

Earlier quoted context omitted.

Yes. What's your point?

Well, if rbx became the default implementation, lots of the effort that was invested in MacRuby would go stale. There's an incentive for the MacRuby people to keep investing into MRI since they can more easily adopt improvements from there. The benefit they get from taking code from MRI will diminish over time, but at least ATM I'd still expect it to be significant. (note: I'm not following MacRuby Development very c…

While MacRuby is a fork, they have already replaced the VM with one that compiles to LLVM, which has been implemented in C++. They have also gutted things like String and Hash to use Objective-C's (or more precisely, Cocoa's) counterparts, and they have started using libdispatch (aka Grand Central Dispatch), Apple's open-source multicore tech.

One of the big things about the new VM is that it eliminates the global interpreter lock, meaning MacRuby probably has much better parallelization than MRI. With the VM alone I think they are on their way to being their own Ruby implementation.

All of this is a bit disappointing considering that they could have shared their improvements upstream and improved MRI performance for everyone, not just for Mac apps.

Re: Work has started on Ruby 2.0

#60

Post by lobster_johnson »

compay wrote: post #58
lobster_johnson wrote: post #57

Earlier quoted context omitted.

Yes. Unfortunately, the balance seems heavily weighted toward the slow end of the curve, so that in practice it comes out slower than MRI. It's not just for things like Rails apps that Ruby is typically used for, either. I frequently process data, such as large log files, and now and then I try out the different Ruby to see if things have gotten better. So far, 1.9 and JRuby are the winners. (LuaJIT is typically 2-5…

Yeah, I agree. Lua is actually my favorite language ahead of Ruby. I have F3 mapped in Vim to run my tests; one of my projects is an implementation of Haml in Lua, and even that runs all of its tests in a small fraction of a second. The more you work with Lua the harder it can be to go back to Ruby sometimes.

I like Lua, but it does lack Ruby's elegance and expressiveness. Its best trait may be that it's simple, and therefore performant.

On my list of gripes: Lua's attempt at OO, being implemented as hash tables, is even more pitiful than JavaScript's. Also, arrays are implemented as hashes (just like PHP!), which is just one notch below JavaScript again. I also wish for a more expressive regex syntax, but then that's the text processing talking.

Post reply on HN