This post describes the new modular garbage collection feature in Ruby 3.4: The ability to override Ruby's GC at runtime. We also introduce our first concrete alternative GC implementation, based on the Memory Management Toolkit (MMTk).
10% less time for the same amount of work, since we are measuring the total response time of the workload in question and looking at median (p50), p90 and p99 numbers.
It is not a dumb question at all. At Shopify we use chruby since it is lightweight and less opinionated. However, devs never really have to use chruby directly, since our in-house `dev` CLI tool can install the Ruby version any project at Shopify specifies and configure `shadowenv` to set the right env variables to use it.
We'd already deployed a prerelease version and started serving all Shopify storefront requests with Ruby 3.2 earlier this week. Here is a Twitter thread from me about all the work that into this release from Shopify with respect to performance and stability: https://twitter.com/paracycle/status/1605706226007941122
If you have any questions, I am more than happy to answer them here. Merry Christmas everyone!
You do realize that market cap is not real money, right? That's like saying that an average American who earns 30K USD/year over 33 years will earn 1M USD and thus they should be considered a millionaire.
I am afraid that is a shared concern for what Tapioca is doing as well. There are ways of mitigating that concern, by, for example, lifting all static methods on a model to be methods on the collection proxy in RBI files. This is certainly doable, and we are less interested in the correct signatures for such methods than having the method definitions in place, in the first place. On the other hand, we also have some Sorbet feature ideas that we want to experiment with where we might be able to annotate that a certain type delegates all missing methods to another type, for example.
This is indeed a problem in our codebase as well, and so far our team has been suggesting that people add shim (i.e. manual) RBI definitions for the methods that they find are missing from the types they've expected them on. This is a good stop-gap measure to solve a problem that is not very common with an easy solution to implement.
We have a lot of automation and infrastructure in place to give us that confidence. We have an extensive test suite of hundreds of thousands of tests, linting and static checks that run on CI, a deploy automation tool that automatically merges and deploys on green (https://shopify.engineering/successfully-merging-work-1000-d...) and a canary deploy system where we quickly detect regressions that might have escaped our systems to that point. We have a lot of posts about those systems written up in our engineering blog, as well.
For the runtime, there is not much dark magic. Each type that has an `extend T::Sig` has `method_added` hooks registered, which notifies Sorbet runtime whenever a method is defined on the type. When that `method_added` hook is called, Sorbet runtime uses the sig flag that you mention to associate the `sig` with the method definition that follows it.
Ultimately, the goal is for Tapioca to replace all `srb rbi` tooling and `sorbet-rails`. Right now, we exclusively use Tapioca for gem RBIs and we don't use any `srb rbi` tooling at Shopify. That works perfectly fine, but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us.
The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 release of the gem that should be able to do that.
Currently, no. On the contrary, since Sorbet syntax is pure Ruby, it needs a runtime component, so there is actually a small negative impact in performance at runtime. The reason why we cannot use types to make the interpreter do optimizations is because the interpreter is not aware of types.
Having said that, such optimizations are indeed possible and we are already thinking about how we can use the type information we have to that effect. There are still many things that need to line up for that to be a thing, so we are not expecting any new developments on this soon. But this is a very exciting direction for our Ruby Infrastructure team at Shopify.
There was definitely some general suspicion when we first introduced Sorbet. However, there were also some early adopters who didn't mind the syntax but really wanted the benefits. That's why we didn't push for types adoption, we allowed teams to adopt (or not) at their own pace. Once people saw the benefits, they wanted more of it. Syntax also stopped being a huge concern.
Quoting from the blogpost:
> - Developers get used to Sorbet syntax over time
> ...
> Our main observation is that developers enjoy Sorbet more as the typing coverage increases.
On the editor integration, the funny thing is that VSCode is the only editor that needs a special extension to integrate with Sorbet. The way Sorbet supports editors is via the built-in Language Server Protocol (LSP) mode which can be used with any LSP plugin for any editor. I know people who are using it with Vim, Sublime Text, etc. Integration is, in a nutshell, running `srb tc --lsp` as a subcommand and piping data in/out via stdin/out. Our tool Spoom actually uses the same LSP mode to provide extra developer tools and analysis on top of Sorbet.
Like others have stated in the thread, Crystal is a different language that shares some its syntax with Ruby. Our aim is to keep our Ruby codebase but adopt static types gradually.