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

71–80 of 134 posts

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

#71

Post by ATsch »

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?

That's just a measure for backwards compatibility, so python2-only scripts don't cause cryptic errors when they have a `python` shebang. Many distros ship without python2, but will probably still link `python -> python2` for the near future.

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

#72

Post by tonyedgecombe »

jonnytran wrote: post #65
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.

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

I've often wondered if part of the problem was supporting Python 2 for so long and hence prolonging the pain.

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

#73

Post by jashmatthews »

pizza234 wrote: post #21
anonova wrote: post #10

Earlier quoted context omitted.

Yes, it was introduced in Ruby 2.6 (2018): https://www.ruby-lang.org/en/news/2018/12/25/ruby-2-6-0-rele...

Well, yes and no (althought the question is a bit open). It's more or less beta quality, and very primitive. It's discouraged to be used with Rails, so I'd be inclined to state that "we didn't get it yet". I'm also personally skeptical that the unusual approach (invoking a whole C compiler in a separate thread) will stand in the long term - but that's my own take.

The CRuby JIT is stable but whether it improves performance or not is workload dependent.

It's simple not primitive. MJIT is designed to take advantage of a C compilers optimization.

"Compile to C" worked for Chicken Scheme for the past 20 years and continues to be a popular way for functional langauges to compile. It's also how Nim works. It's all about different trade-offs.

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

#74

Post by oblio »

jashmatthews wrote: post #73
pizza234 wrote: post #21

Earlier quoted context omitted.

Well, yes and no (althought the question is a bit open). It's more or less beta quality, and very primitive. It's discouraged to be used with Rails, so I'd be inclined to state that "we didn't get it yet". I'm also personally skeptical that the unusual approach (invoking a whole C compiler in a separate thread) will stand in the long term - but that's my own take.

The CRuby JIT is stable but whether it improves performance or not is workload dependent. It's simple not primitive. MJIT is designed to take advantage of a C compilers optimization. "Compile to C" worked for Chicken Scheme for the past 20 years and continues to be a popular way for functional langauges to compile. It's also how Nim works. It's all about different trade-offs.

Chicken Scheme compiles ahead of time, doesn't it?

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

#76

Post by randomdata »

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!

At that rate, next you're going to tell us that Go is going to get generics.

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

#77

Post by rightbyte »

tonyedgecombe wrote: post #72
jonnytran wrote: post #65

Earlier quoted context omitted.

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

I've often wondered if part of the problem was supporting Python 2 for so long and hence prolonging the pain.

Without that I think many would lose trust in Python and just switch language.

I mean it has only been 11 years since Python 3.1/2.7 and that's probably a common lifespan for maintenance mode code projects? 3.5 is still supported and that one is 5 years old. Why the hurry.

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

#79

Post by pansa2 »

jonnytran wrote: post #65
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.

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

> I can't help but contrast this with the upgrade from Ruby 1.8 to 1.9.

One difference is that upgrading Ruby from 1.8 to 1.9 brought a significant performance increase, whereas going from Python 2.x to early 3.x, performance actually got worse.

AFAICT this was mostly caused by the removal of the machine-word-sized integer type - in Python 3, even 1+1 is calculated using arbitrary-precision integers.

Python 2 => 3 had lots of other problems as well - ultimately they changed just enough to break everyone’s code, but not enough to make upgrading worthwhile.

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

#80

Post by daenney »

randomdata wrote: post #76
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!

At that rate, next you're going to tell us that Go is going to get generics.

Yes. https://www.reddit.com/r/golang/comments/idwylv/moving_forwa...
Post reply on HN