ufuk

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

That's not correct:

    $ podman run -it -e RUBYOPT="--yjit" ruby:3.2
    irb(main):001:0> puts RUBY_DESCRIPTION
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux]
    => nil

You can see this chart and all the numbers and more at https://speed.yjit.org/, which this chart was taken from.

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.

As far as I know, yes, it should. But I haven't tested it so I can't say for sure.

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.

This is a great first step to making dependencies more secure in the Ruby ecosystem. Congrats to the whole team for getting this done!

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.

It is, more or less, an implementation of this idea: https://yehudakatz.com/2009/07/11/python-decorators-in-ruby/

This is a great way to use Sorbet and get its benefits without having to invest 100% into typing. Great example, thanks for sharing.

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.

Happy to answer any questions here about our process, results or tools!

The second part of this two-part blogpost is here: https://shopify.engineering/adopting-sorbet

Great story, however, I am afraid, not at all relevant to this product. This Google Assistant feature is supposed to surface "solutions journalism" pieces where the article not only talks about the problems but also potential solutions that are being tested or successfully applied elsewhere.

So the stories are "good" not in the sense of not covering disturbing events but they are "good" in the sense that they offer solutions or ways out of problems. It is not about "what" is covered but more about "how" it is covered.

"Pure"?

Well, somebody's got to do the thinking...

Author of the project here... Thanks for the visibility and all the comments. Feel free to ask me anything and/or submit PRs.

So pleased to hear that. I'd had enough of hunting around different sites trying to find and test different themes for Slack, so I built one as a weekend project. Enjoy.

Hi! Author of the project here... Sorry you found it disturbing, the intention was to encode the selected theme in the URL so that it can be easily linked to, etc. Maybe I should look into trying to do that with replaceState. Having said that, the code is open-source and PRs are always welcome. ;)

I would assume any brand with an ounce of wits would not choose to spend time and money trying to reach users who have explicitly stated that they have no interest in the topic. Especially when there always is a whole bunch out there how are clamoring for said topic.

Still, I must confess there are many brands who have yet to reach this level of understanding, but that doesn't mean services would necessarily choose to enable those types.

Why does the Terms and Conditions document (https://www.sharelatex.com/termsAndConditions.html) refer to Automattic Inc.? Is that a leftover from a quick copy and paste?

I don't understand why not much has been said about Android on exactly this topic.

The article complains mainly about two issues both of which are solved by the Android platform:

1) The keeping-applications-up-to-date problem has been addressed by the auto-update mechanism introduced by a market update for some time now. The apps are updated silently in the background without any user-interaction whatsoever. That's exactly what Chrome does for the web. If you keep Chrome open for decades then you web app will not upgrade either, at least not in the way you think it will.

2) The every-app-is-an-island problem is symptomatic of iOS since you are only allowed access as Apple sees fit. However, this is a solved problem on the Android platform through the use of Intents and the Back button which works as good as any web linking would.

Well, according to the documentation that folder is backed up to iTunes as well. Actually, it seems, the only folder that skips backups to iTunes in the Library folder is the Caches folder.

The relevant part of the documentation is here: http://developer.apple.com/library/mac/#documentation/FileMa...