51–60 of 134 posts
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?
I’m excited about performance improvements but thrilled at the idea of adding types. Has anyone here worked with Sorbet or a prerelease 3.0 in Rails and able to share some notes?
The sorbet demo (https://sorbet.run/) is all I could wish for (you can remove the type signatures and see that it would still warn you about the `.barr` typo).
However, it is still a great deal of work to set it up on Rails (Sorbet is made by Stripe, they use Ruby but not Rails), and I couldn't finish the setup because of some gem warnings that I couldn't updated at the time.
Hope to give it another try soon!
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.
Are they going to make non-backward-compatible changes, or is this just a marketing move?
They aren't that exciting, but they are necessary to eliminate some ambiguous and inconsistent cases, and will be a pain for some codebases. (2.7 already marks as deprecated behavior that will break in 3).
https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...
I'm not sure if ruby actually commits to semver-style no-backwards-incompat-unless-major; they didn't used to. Either way though, recent ruby minor version releases have seen few if any (?) backwards incompat changes of any note -- nothing of note I can think of since 1.9 in 2007 (which did have major changes. Ironically 2.0 didn't have so much). The keyword arg changes will definitely effect more codebases more significantly than any we've seen in a while.
I’m excited about performance improvements but thrilled at the idea of adding types. Has anyone here worked with Sorbet or a prerelease 3.0 in Rails and able to share some notes?
Like most non-trivial Rails apps, our test suite takes a while to run, so I like having Sorbet to catch "dumb" issues without having to run the full suite. Running `srb tc` to check types is incredibly fast and seems to be scaling well as our codebase grows. It catches the obvious stuff, but has also found some subtle bugs in flow checking and is great for refactoring support. The false positive rate is extremely low - if Sorbet flags a regression in your type checking, it's very likely to be a real bug.
The Slack community is helpful and responsive - if you're thinking of using sorbet, I'd strongly suggest joining.
The downsides are:
- Unclear workflows - it's hard to know when you need to "rescan" for new type definitions in gems, the stdlib, and in generated code in your own app
- Poor Rails integration - the sorbet-rails package is helpful and being actively developed, but it's clear that the maintainers don't use Rails and aren't going out of their way to support it.
- Upgrades are rough - the sorbet tools that scan your gems and code to find "hidden definitions" are seemingly unstable from release to release. There's a good chance that upgrading to a new version of sorbet will break your type checking for mysterious and hard-to-debug reasons. Lots of this is probably related to Rails as well.
- IDE integration isn't quite ready for prime-time yet. I've gotten it working in Emacs with lots of experimentation and poking around, and I think some folks have it working in VSCode too, but it's not officially "released" or supported and it crashes somewhat often. It's still stable enough to be useful and I'm glad I have it.
It's great and seems to be getting better, and it has absolutely made me more productive, but know that you're still adopting an alpha- or beta-quality tool and it's unlikely to "just work".
Are they going to make non-backward-compatible changes, or is this just a marketing move?
Ruby 3 is expected to introduce new concurrency primitives that evade the global interpreter lock (guilds / isolates) and type definitions for the stdlib for optional typing support. This should be a big release for ruby!
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?
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?
Earlier quoted context omitted.
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
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!
The Crystal programming language might also reach 1.0 this year too. Towards Crystal 1.0 : https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html