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
Static Typing for Ruby: Adopting Sorbet at Scale
51–60 of 72 posts
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#52Isn'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.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#53Earlier 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
This is a thing?
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#54How? Do they track all of their devs commands?
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?
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
#56Earlier 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…
(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
#57Earlier 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.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#58I 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…
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
#59Earlier 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?
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#60At 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.