So many JS projects are switching to TS, but AFAIK the same isn't happening within Ruby, which reduces some of the type-checking benefit.
Also, this is subjective but I don't like the syntax.
> Sorbet is 100% compatible with Ruby. It type checks normal method definitions, and introduces backwards-compatible syntax for method signatures.
I would have preferred if they had introduced a compile step the way typescript does, and provided a TS-like syntax. I find the current version hard to read.
> So many JS projects are switching to TS, but AFAIK the same isn't happening within Ruby
The sheer propagation of JS might have something to do with the big push to have some kind of typing. From my own experience, if I see ruby I know I can either re-write it or find an alternative in TS/JS.
The ubiquity of JS makes it more accessible, but I'm still trying to find reasons why one would choose Ruby.. I'm always a 'right tool for the job' but I don't know what the niche is.
Edit : My pedant in me :
> compile step the way typescript doe
Typescript transpiles to JS. I don't 'believe' there is a compilation step.
> Typescript transpiles to JS. I don't 'believe' there is a compilation step.
This is a common misconception. Transpiling is not something distinct from compiling. "Transpiler" is just a trendy name for a certain subset of compilers. Just because it compiles to another "high level" language doesn't mean it's not a compiler.
Every "transpiler" is a compiler.
Sources:
On BIX in the 1980s, when the only implementation of C++ was Cfront, which translated to C, I asked Bjarne Stroustrup if it was a preprocessor. He told me quite emphatically, "No, Cfront is a compiler." (I don't think the term "transpiler" was in common use at that time.)
The Wikipedia article on Cfront agrees:
> Cfront was the original compiler for C++ (then known as "C with Classes") from around 1983, which converted C++ to C
TS has a way to attach type annotations (.d.ts files) on top of existing JS code base, thus allowing for gradual migration and relatively peaceful coexistence. Same with Python: you can add type definitions on top of existing untyped code, as a separate package. In either case, types can be provided by a third party, e.g. yourself if you want to use a particular library and it still lacks typing support.
Does Sorbet offer something comparable? That would make adoption easier.
The problem (as TFA points out) is that most of the available options (including "a TS-like syntax") are already valid Ruby code.
I do agree with your first point that the lack of adoption of Sorbet among library maintainers negates some of the benefit of the type system (compared to TS). Seeing all those `T.untyped`'s in generated RBI files is a little scary :D.
