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.
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!
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.
Muchas gracias. Got distracted by Christmas day familial activities and didn't realise you'd replied.
ps: my sis uses Shopify to run her entire online biz and even though I'm the supposedly techie one she's the one that set it up, configured it, and runs it – she wouldn't know what a Ruby is!
New shell instances load much faster when running asdf instead of rbenv/nvm/etc… instead of having multiple processes checking multiple dotfiles for a given environment there is just a process and single file.
You are too optimistic. The js mind virus is spreading inside fast. The old devs' moving up, the new naive devs' moving in. Web tech is heading towards what tech influencers and companies making money of. You will never see shiny VC backed companies pumping Rust outside of the bubbles.
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.
Your comparison is still flawed. Market cap is the value of the company in the eyes of its investors, which in theory factors in current assets, current profits, and future expectation of profits. You compared that to the net worth of a single individual, which accounts for nothing but current assets.
That said, you weren't all that far off. Based on Shopify's revenue of $4.6 billion and an average household income of $67k, this is equivalent to a donation of $14.57.
I still argue that the presence of this kind of negativity in every thread about corporate donations is toxic. Corporations don't donate to FOSS nearly as often as they should, and there's no harm in giving them some credit on the rare occasions when it happens.
Shopify's revenue last year was $4.6m last year, and that's before expenses, so I'd say it's quite a meaningful contribution. But regardless, a $1m donated to OSS is still $1m.
If you want to talk crap about a company that gives 0.002% of their "market cap" to FOSS development, at least be ready to show that you are doing better than that. Otherwise, your indignation sounds like nothing but a mere cheap attempt at virtue signalling, and FOSS devs can not use that to pay their bills.
What amazes me is they are giving money with no strings attached, and of course there will be some entitled prick who will try to find fault at that. I wish more companies did "PR stunts" like these...
TFA truly was a blessing for security. Finally _something_ that can just be blindly mandated and actually works wonders. User training was not getting anywhere.
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.
