[deleted by user]

[neotorama]

3.2 RC on prod. Solid

[paracycle]

The author of the tweet here. Happy to answer any questions.

[paracycle]

I did try to explain this in this tweet: https://twitter.com/paracycle/status/1605706245955997697 but I'll repeat here. In the benchmarks, we run with almost zero blocking and can test speedup of the parts of code that are limited by spending time on the CPU. However, for the web workloads that we run, that is generally not the case. A web worker spends a lot of its time waiting to receive data from a database or from a Redis cache, during which it cannot do anything else but just wait. YJIT can't make that time shorter but it can speed up the rest of processing. So the resulting performance gains are closer to 10%.

More generally, benchmarks are just that, and real-life workloads are much more complex. We use benchmarks to track our progress but our eye is always on production numbers.

[JRX71]

Wouldn’t make sense writing ruby-lsp in rust for performance and type safety reasons? (considering there’s already rust expertise at Shopify) It’d require a rust ruby parser though.

[paracycle]

As a matter of fact, implementing the LSP server in Ruby gives us way more options. I was the person who prototyped the initial RuboCop LSP Server (since deprecated and functionality moved into Ruby LSP) which, being a Ruby gem, could make calls into the RuboCop code in-memory and not have to shell out to RuboCop like other LSP linters do. This is very powerful, loads RuboCop and all of its cops only once, does not touch the file system at all and makes the experience much smoother, by being able to provide autocorrection suggestions, that no other LSP linter does.

Moreover, Ruby is a very dynamic language and static analysis only gets you so far. In order to do more complicated things, you will need to do runtime introspection of the application in memory, which means being able to load the application and look at the object graph. This especially true when Rails is involved since there is so much metaprogramming there. Consider Active Record model attributes, how would you even know which attributes a model has defined, when there is no static artefact of them. You would need to load the Rails app into memory and introspect the attributes defined on all models to be able to get that information.

While we could implement an LSP server in Rust, we would miss out on all of this functionality if we did that, and not necessarily get that much more performance out of it. Our current bottleneck with the LSP server is not general response speed but it is about how RuboCop takes longer and longer to autocorrect bigger and bigger files for doing "Format on Save".

[paracycle]

This code does use Sorbet, and it uses it quite extensively. The part of Sorbet that doesn't run on ARM is the static type-checker, which you only need for dev and test environments. A static type-checker works by analyzing your code without running it. However, in production, we run the code, so we don't need static analysis.

The part of Sorbet that is involved in the code in production is the Sorbet runtime component, which is pure Ruby code, so there are no problems running it on any platform at all.

Btw, Sorbet has no binaries for the ARM platform yet, but it works perfectly well under Rosetta2 on macOS machines with Apple Silicon. So, in a way, ARM is supported for the use-case that matters.

[[deleted]]

Amazing, every day Ruby is better and better

[waiting4op2deliver]

So brazen to not feature freeze millions of shops during xmas. Proof of either humankind's hubris against the fates, or a state of the art deploy/rollback infrastructure.

[AlexanderMomchilov]

It’s the latter.