Live data from Hacker News

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

github.com

41–50 of 134 posts

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

#41
post #5

Are they going to make non-backward-compatible changes, or is this just a marketing move?

looks like they're adding an optional type system, which means you get the worst of both worlds- no guarantees AND no compile-time type checking (think: what happens if type-checked code calls non-typed code?) so I have no idea how they're going to make that fast since all types will still have to be checked at runtime

It works great for Python.

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

#42
post #18

Earlier quoted context omitted.

Are you sure it’ll be awful? Sorbet ( https://sorbet.org/ ) is pretty popular already. It can statically check your whole project and dynamically check it at runtime. It also doesn’t add that much overhead so I’m not sure what you’re on about...

Sorbet looks really cool, too bad they developed their own typing system that keeps types in a totally separate file instead of adopting it.

The 'separate' file is to avoid breaking backwards compatibility and avoiding a Python2/3 fiasco

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

#43
post #9

Earlier quoted context omitted.

The goal of Ruby v3 is to be 3 times faster than v2. https://blog.heroku.com/ruby-3-by-3/ Unclear if that goal has been achieved.

From benchmarks [1], 2.8.0 (with jit) is ~2x faster than 2.0.0p648 [2]. [1]: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b... [2]: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...

notice the "3x3" goal is on a specific benchmark (optcarrot), not on all workloads.

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

#45
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.

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

So from the perspective of an application developer who uses package dependencies, using Python 2 was the norm until 2015 at the earliest? That sounds about right to me.

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

#46
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.

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

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

#47
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!

Spark 3 was released this year: https://databricks.com/blog/2020/06/18/introducing-apache-sp...

Almost entirely backwards compatible with huge performance gains.

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

#49
post #18

Earlier quoted context omitted.

Are you sure it’ll be awful? Sorbet ( https://sorbet.org/ ) is pretty popular already. It can statically check your whole project and dynamically check it at runtime. It also doesn’t add that much overhead so I’m not sure what you’re on about...

Sorbet looks really cool, too bad they developed their own typing system that keeps types in a totally separate file instead of adopting it.

Sorbet will be compatible with the new file format. We’ll still be able to use the inline Sorbet type signatures.

My personal hope is that typing can be included in test/spec files.

Post reply on HN