sorbet VS rbs

...which goes beyond static typing into declaring explicitly what something needs to support to be used by the method. Granted this is more complicated than it sounds and has a number of drawbacks, as you can see in this discussion.

Not part of the official language spec, but Ruby has Sorbet, from a company who employs Ruby core contributors and helped with the recently released JIT additions to the language, amount countless other contributions over the last couple decades.

https://sorbet.org/

First let's introduce the tool: Sorbet is a gem developed by Stripe that aims to bring type notation syntax and type checking support for the Ruby ecosystem by utilizing the "Gradual typing" philosophy, it also provide type generation from YARD comments via the tapioca gem, allowing to grow alongside the already built Ruby codebase.

We have hundreds of thousands of lines of ruby code spanning many services / monoliths. Even now I find it somewhat annoying to open a controller / component that is basically an empty class def but somehow executes a bunch of complex stuff via mixins, monkey patches etc, and you have to figure out how.

We are turning to https://sorbet.org/ to reign in the madness. I'm keen to know if others are doing the same, and how they are finding it (pros and cons)

According to https://sorbet.org/ , the vast majority of code at Stripe is written in ruby.

Caso de Stripe, que tuvo que inventar Sorbet para tener type checking en ruby.

> I guess what I'm asking is: do you see a future where there is more explicit control afforded to people who want to pick their own tradeoffs without resorting to writing everything performance-sensitive in extensions written in C/Rust/whatever?

An approach exists already in the present, and it's Stripe's Sorbet AOT compiler (https://github.com/sorbet/sorbet/tree/master/compiler).

I saw no mention of RBS+Steep, the latter providing a LSP. I use it a lot and very much like it, although it's still young and needs love, but it's making good, steady progress! I've been very pleasantly surprised by some of the crazy things Steep can catch, completely statically!

You appear to be working on projects with Sorbet (which I tried to like but found it fell short in practice, notably outside of the app use case i.e it's mostly useless for gems) so it may be a tall order to try on those. Maybe you can give RBS+Steep a shot on some small project?

RBS: https://github.com/ruby/rbs

RBS collection (for those gems that don't ship RBS signatures in `sig`, integrates with bundler): https://github.com/ruby/gem_rbs_collection

Steep: https://github.com/soutaro/steep

VS Code: https://github.com/soutaro/steep-vscode

Sublime Text: https://github.com/sublimelsp/LSP

Vim (I'm working on it): https://github.com/dense-analysis/ale/pull/4671

I don't know what you mean by "Static typing is not webscale".

> https://news.ycombinator.com/item?id=39159481

Bugs exist in all code written in all programming languages and you will find bugs in programs written in statically typed languages too as you know. Programming languages are rarely chosen for the absense of bugs alone though or we'd all be using SPARK Ada or something.

> spitting out code as fast as your keyboard works, or is is not having features do weirdo things

This is a straw man. No-one has suggested that "spitting out code as fast as your keyboard works" is what Rails allows you to do, or that Ruby code results in features that "do weirdo things".

In reality engineer productivity is important and Rails enables it in a web environment.

> I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context.

Yes, I prefer writing statically typed languages and I would /greatly/ prefer Ruby to be statically typed for a number of reasons, but it will likely never be so in a way I consider to be usable (see https://github.com/ruby/rbs). Not being able to definitively tell what a method returns or where one is defined is a total PITA, but it's one of the array of up and downsides to Ruby, with each language having a different set.

> I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature.

You don't need to know how all of Rails works to write a Rails app, as I'm sure you know, so this seems like another mis-representation of the truth, just as you don't need to know how the compiler or CPUs work to do a lot of (most?) programming.

> That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing

You seem to be suggesting that Ruby on Rails applications behave unpredictably on a machine to machine basis but that's not really how Ruby works in practice, or matching on my experience.

Are you familiar with rbs (https://github.com/ruby/rbs)? If so, what issues do you see with using that over TypeScript?

Ruby does have optional type annotations, if you want them:

https://github.com/ruby/rbs

Is anyone using RBS? Or, is it still half-baked? I haven't seen any recent posts about it this year. Though, I see the repo has some recent activity.

Currently rbs collection resolves stdlib dependencies, but rbs -r LIB option doesn't resolve them unfortunately. For instance, logger depends on monitor, but rbs -r logger doesn't load monitor.

Here is link number 1 - Previous text "RBS"

Partial clone reduces the impact, but it just procrastinates the problems.