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...
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.
FWIW the GIL has been the GVL since YARV was merged in and it became based on a virtual machine rather than purely interpreted. I believe this was 2.0.
> because the number of copies you run will be proportional to the number of cores you have, not the number of machines
While this is true, Ruby is also very CoW optimized so while forks grow linerally in size (with count), usually the first fork is drastically smaller than the process it was forked from.
I work at Heroku and recommend perf settings to customers. 5 years ago people were mostly hitting memory limits. Now it's pretty common to see apps that are maxing out the CPU well before coming close to ram limits.
Especially when compared to javascript, Ruby is extremely memory efficient.
I agree with your larger statement but wanted to chime in and expand on those two points.
CRuby forks using fork() and Copy-on-Write shares memory from parent to child.
JRuby doesn't have a GIL so you only need a single process. Same with TruffleRuby.
With CRuby, you're much better to run a bigger container with multiple processes than one process per container.
With either NodeJS or CRuby you're still better to run less containers on bigger hosts. Each host has to duplicate the host OS and container infrastructure. Each container of a real production app also duplicates a bunch of stuff despite Docker's best attempts at sharing.
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!
Towards Crystal 1.0:
https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
Here is a walkthrough:
(Or Java getting new maintainers...)
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.
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.
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.
Or not... it's not like you can't throw a python 3 dev at an old python 2 codebase and tell them to work on it. Even if that probably wouldn't make them very happy about it, they wouldn't be lost.
But I'd bet an arm that there will still be python 2 codebases running in production in the next decades with companies very unwilling to do the work of migrating it.
https://devblogs.microsoft.com/powershell/announcing-PowerSh...
I don't know that it's certain it ever will be default on Windows, IIRC the last things I read were that it might become an optional package in Windows.
[1] Six-monthly, now moving to annually to align with new versions of .Net Core.
Almost entirely backwards compatible with huge performance gains.
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".
j/k. sorbet-rails maintainer here. I agree with the assessment that sorbet doesn't go out of the way to support some Rails feature, eg method overloading or scoping block accurately. Sorbet tool is opinionated about some of the design choices that makes it hard to support Rails' extensive use of meta-programming. That said, Sorbet is still useful in checking the custom code we write on top of Rails and their interactions. It may be hard to type the model files themselves, but we can type-check the code making use of the models! Recently, I started a new project on Rails and it's quite fun building it with type from scratch :D
I find Sorbet a very helpful tool for development. I hope people will give it a try and contribute to tools around it (sorbet-rails included) so that we have great tools to use!
For those who are interested in the topic, I outlined some of the technical challenges with using Sorbet on rails here https://medium.com/czi-technology/static-type-checking-in-ra...
But I do have the sense that building Rails apps using sorbet won't feel "first class" until we have some sorbet maintainers that use Rails or the Rails team starts adopting sorbet (or both!)
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!
We defined a new language called RBS for type signatures for Ruby 3. The signatures are written in .rbs files which is different from Ruby code. You can consider the .rbs files are similar to .d.ts files in TypeScript or .h files in C/C++/ObjC. The benefit of having different files is it doesn't require changing Ruby code to start type checking. You can opt-in type checking safely without changing any part of your workflow.[1]
So UX-wise I don't know. While it's nice to have them separated, you are just faster if you have types in the code in front of your face when the IDE warns. Otherwise you will context-switch on any warning/error. This could get significant since you code just based on the LSP's output sometimes for hours. The IDE could help here with showing the definition when warning but still, if you want to change the definition or want to see more than just a snippet you will constantly jump between files.
Also .d.ts files were introduced to type old code and as an fallback and as a secondary option, At some point, Matz and Soutaro need to integrate types into the language itself to get the same level of productivity other typed languages offer, eg. Rust/Go/TS.
The next thing is IDE support, anyone knows more?
[1] https://developer.squareup.com/blog/the-state-of-ruby-3-typi...
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.
[1]: https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...
https://blog.heroku.com/ruby-3-by-3/
Unclear if that goal has been achieved.
[1]: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b...
[2]: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...
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.
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.
If you use bootsnap, you use ".rbc" files already.
