Live data from Hacker News

Static Typing for Ruby: Adopting Sorbet at Scale

shopify.engineering

51–60 of 72 posts

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#51

Earlier quoted context omitted.

> hijack a running process and change memory without leaving a trace Doesn't sound like a Ruby problem.

No but, Ruby makes it trivial. No decompilations, no assembly, no debuggers necessary. Drop into an irb in a running process, change stuff and get out in seconds

Compilation is not a security control. Also if you're handling transactions at a significant rate, PCI (with all its problems) makes sure there's a trace.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#52
post #5

Isn't crystal lang trying to do the same thing? Why not join forces?

Beyond the syntax looking a bit similar, Crystal is a very different language. Porting over a production application such as Shopify isn't something you do in an evening.

It goes past syntax. Yes, they're different languages, but syntax, behaviour, stdlib are so close you can port non-trivial libraries between them in a relatively short time.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#53

Earlier quoted context omitted.

> hijack a running process and change memory without leaving a trace Doesn't sound like a Ruby problem.

No but, Ruby makes it trivial. No decompilations, no assembly, no debuggers necessary. Drop into an irb in a running process, change stuff and get out in seconds

> drop into an irb in a running process

This is a thing?

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#55

> Finally, we track how many times our developers ran the command dev tc to typecheck a project with Sorbet on their development machine. How? Do they track all of their devs commands?

`dev tc` is a command at Shopify that runs Sorbet. I'm assuming they instrument all subcommands of their `dev` command and send aggregate statistics to an internal statsd service.

We do the same thing where I work. If you're working on a developer productivity team, the service whose SLA you're responsible for is the dev tools, so it's critical to know how long they take, which commands are run most frequently, etc.

In fact, Sorbet, has this built in: you can give it an assortment of `--metrics-...` [1] and `--statsd-...` [2] flags that configure Sorbet to talk to a statsd service directly:

[1] https://sorbet.org/docs/metrics

[2] https://sorbet.org/docs/metrics#reporting-metrics-directly-t...

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#56
post #29
post #22

Earlier quoted context omitted.

Do you have any tips or tricks for migrating a Rails app from Sorbet `srb rbi` generated files to one using Tapioca? I was unsure exactly which bits of Sorbet rbi were still required with tapioca https://github.com/Shopify/tapioca/issues/114 We are currently using `sorbet-rails` but it appears Tapioca would be a replacement for that as well, is that correct?

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 releas…

One of the challenges sorbet-rails faced [1] was with the usage of method_missing in certain places. The one that bit me was Rails automatically piping a class method from Model into the Model's CollectionProxy, effectively making class methods into scopes. We use this pretty extensively at work for complex scopes, so this is one of the reasons I've not been able to get complete buy-in for sorbet. Is that better in tapioca?

(Also: Thank you for sorbet! It's the biggest reason I continue to use Ruby for my personal projects.)

1: https://github.com/chanzuckerberg/sorbet-rails/issues/104

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#57

Earlier quoted context omitted.

Beyond the syntax looking a bit similar, Crystal is a very different language. Porting over a production application such as Shopify isn't something you do in an evening.

It goes past syntax. Yes, they're different languages, but syntax, behaviour, stdlib are so close you can port non-trivial libraries between them in a relatively short time.

The key word there is non trivial. Something with as many moving parts as Rails is non trivial, and Crystal doesn't have the run-time metaprogramming that Rails makes extensive use of. A trivial example is ActiveRecord generating attribute methods from your `select` operation.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#58
post #50

I keep looking at Sorbet, and I have since it was in private beta. It just seems to be so so much work to get anything out of it. Last time I tried it was last year when I was at Rubyconf in my spare time on a microservice. It's frankly easier for me to rewrite a small service in Rust, and have native typing (plus thread safety, no race conditions, easy parallelism, etc). While I'm best at Ruby, and have used it prof…

Somewhat intentionally, there is no doc page on "Starting a new project with Sorbet" only "Adopting Sorbet in an existing codebase"—Sorbet was built for and delivers the most value to large, existing Ruby codebases.

You'll also notice the three selling points on the home page:

- It's fast (it has to be, else it wouldn't work in large existing codebases)

- It's IDE ready (so that a dev tooling team can go to their organization and say "if we adopt this, the IDE features will make our engineers more productive")

- It's gradual (so that typed and untyped code lives side by side)

If you have the luxury of starting from scratch, there are far better ways to ensure 100% type coverage from day 1. Unfortunately, companies like Shopify and Stripe don't have that luxury, and are contending with hundreds of developers who maintain millions of lines of Ruby code.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#59

Earlier quoted context omitted.

No but, Ruby makes it trivial. No decompilations, no assembly, no debuggers necessary. Drop into an irb in a running process, change stuff and get out in seconds

> drop into an irb in a running process This is a thing?

It also is a thing in most other languages, including C, Python, Java, Erlang, ...

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#60

At this point Ruby (which is still slow and dynamic compared to most other faster languages) looks like a sunk cost. Only reason why it's still alive is Rails, I don't see much hope for it longer term, Crystal and Elixir does IMO. Using Ruby/Sorbet screams using JS/Flow to me, instead of using a language with types built in.

Obviously programming language preferences are like favorite flavors of ice cream, but Ruby is still the best scripting language there is IMHO.
Post reply on HN