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
Ruby: We have decided to go forward to 3.0 this year
41–50 of 134 posts
Re: Ruby: We have decided to go forward to 3.0 this year
#42Earlier 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.
Re: Ruby: We have decided to go forward to 3.0 this year
#43Earlier 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...
Re: Ruby: We have decided to go forward to 3.0 this year
#44Re: Ruby: We have decided to go forward to 3.0 this year
#45What 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.
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
#46What 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.
Re: Ruby: We have decided to go forward to 3.0 this year
#47What 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!
Almost entirely backwards compatible with huge performance gains.
Re: Ruby: We have decided to go forward to 3.0 this year
#48Re: Ruby: We have decided to go forward to 3.0 this year
#49Earlier 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.
My personal hope is that typing can be included in test/spec files.
Re: Ruby: We have decided to go forward to 3.0 this year
#50Did we get JIT?