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

Ruby: We have decided to go forward to 3.0 this year

github.com

Post reply on HN
Print view View original

61–70 of 134 posts

Re: Ruby: We have decided to go forward to 3.0 this year

#61

Post by cortesoft »

Alex3917 wrote: post #39
mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

Someone forgot to tell my company...

Re: Ruby: We have decided to go forward to 3.0 this year

#62

Post by byroot »

ljm wrote: post #50
maxpert wrote: post #7

Did we get JIT?

I wonder what happened to that old planned feature where the ruby code would be byte-compiled into .rbc files?

The capability is there since 2.3 at least, but Matz doesn't want it by default, and prefer to leave it to libraries.

If you use bootsnap, you use ".rbc" files already.

Source: https://bugs.ruby-lang.org/issues/16847#note-14

Re: Ruby: We have decided to go forward to 3.0 this year

#63

Post by chaostheory »

Alex3917 wrote: post #39
mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

I beg to differ as someone who's been forced to use python 2 at work until next year. As for the python ecosystem as whole, it feels at the earliest the transition to 3 had to be around 2017 - 2018 before most popular libraries got with the program. Then again the numbers could prove me completely wrong. I just remember personal pain points well. By comparison, the Ruby ecosystem was much faster in transitioning.

Re: Ruby: We have decided to go forward to 3.0 this year

#64

Post by dharmab »

framecowbird wrote: post #46
Alex3917 wrote: post #39

Earlier quoted context omitted.

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

most Linux distros still have Python 2 as the default though, right?

Only server/LTS versions which need Python 2 for backwards compatibility.

Re: Ruby: We have decided to go forward to 3.0 this year

#65

Post by jonnytran »

Alex3917 wrote: post #39
mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

This is simply not true. From 2014 to 2017, I worked at a place where I kept starting new projects in Python 3. But people with less foresight wouldn't let their Python 2 habits die. It was a constant struggle to get anyone to realize that Python 3 was the future, and the majority of the code ended up using Python 2. In 2019 when the end-of-life for Python 2 was finally announced, I knew of companies scrambling to upgrade.

I can't help but contrast this with the upgrade from Ruby 1.8 to 1.9. It was also painful, but no one in the community was holding on to 1.8 years later.

Re: Ruby: We have decided to go forward to 3.0 this year

#67

Post by unfunco »

shinepl10 wrote: post #6
mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

You forgot about PHP going to v8

The current major version of PHP is 7 so that makes sense, it was really the jump from 5 to 7 which was a little anomalous.

Re: Ruby: We have decided to go forward to 3.0 this year

#70

Post by hinkley »

owens99 wrote: post #33
tiffanyh wrote: post #28

It appears that Ruby 3 might come short of their 3x speedup goal [1][2] ... has anyone tried out Graal/TruffleRuby? Graal/TruffleRuby has shown some massive perf increases [3] [1] https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a... [2] https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b... [3] https://www.reddit.com/r/ruby/comments/b4c2lx/truffleruby_be...

Look for tenderlove’s comments on TruffleRuby. The performance is at the expense of memory.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores.

I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will make more sense. If 8 cores benefit from a shared footprint, instead of one core per process, then the budget looks more attractive.

So now might not be the right time to cherry-pick some of these features, but it may not be far off.

Post reply on HN