I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context.
But what is the point of the recent wave of types for python, Ruby, and similar languages?
If it’s type safety you want there, there’s a bajillion other languages you can use right?
I think this is a nice way to include types into a project if you like it. I know when you're working on large Ruby projects - 10s of thousands of lines across hundreds of files - types become really, really helpful to figure out what on earth is happening where. In the past I've used DryRb and was pretty happy with it; but an even deeper connection, like this, looks wonderful.
I'd really enjoy it, I think :)
Dynamic languages have amazing dev speed, but once code matures, slapping some types on that code is just plucking low hanging fruit. It inevitably picks up easy bugs and makes the code easier to read, understand, and maintain.
Ruby has had no good solution to dynamic typing, for reasons well articulated by the linked piece. Honestly, that kept me from writing much Ruby recently. Every line just felt like instant tech debt, short of any sensible pathway to static analysis.
This might just get me writing some Ruby again.
This is an interesting proposal. But for posterity I am going to critique the critique on the website about Sorbet:
Sorbet is Ruby and while it has a DSL that is no different than any other gem providing methods or objects to use. For example you can define a type and assign it to a Ruby constant. Because Sorbet is Ruby.
In general I would say any type system has its own syntax when you go deep into it and need more than this param has this simple primitive type and the method returns this simple primitive type. So you have to learn a DSL and the syntax of a type system.
Otherwise, I think in terms of typed Ruby, this is an incredible undertaking with very well written documentation. Thank you for making this library, I think there's a lot that the Ruby community can benefit from with it. Cheers!
I think low_type is a much more elegant solution: https://github.com/low-rb/low_type
I've seen some mention Crystal as well, but as far as I know, Crystal has nothing to do with Ruby except sharing similar syntax. Their semantics are completely different. It's not Ruby + types.
The website is quite extensive, but the gem only has ~1.5k downloads. It’s presumably very early on the adoption curve
def greet(name: String): String
Instead of arrows like rbs files? Why diverge from precedent? def greet: (name: String) -> StringI never tried “typed Lua” variants (such as MoonScript IIRC), but I believe those do require a compilation step.
The playground seems broken, I can't get it to report any kind of error. It seems to accept even syntactically incorrect files (e.g. just one unmatched closing parenthesis).
I'm not saying we (humans) don't need type checkers and I love TypeScript, but something is happening where AI might theoretically surpass the power of traditional type checking. Have the power to catch even more invalid code than the static analysis tools, linting tools, etc.. we have now.
You can't tell anything about an instance variable in ruby if it can be set from anywhere. Of course it's a special case
Edit: I see sorbet supports this as an experimental feature https://sorbet.org/docs/rbs-support
Oh well.
def greet(name: String): String
"Hello, #{name}!"
end
Yep - looks like utter s...I understand that many programmers come from languages where their brain has been adjusted to necessitate and depend on types. And they get help from the compiler in capturing some errors. But it is the wrong way to think about programs and logic. I'd wish these guys would stop trying to ruin existing languages. Go add types somewhere else please.
Note: I also use java, so I am not against types per se. I am against a want-on need to slap down types onto everything and your Grandma, merely because your brain (of type afficionados) needs them for survival.
in most of my coding career (rails) i have not needed types. But when i was working on a large codebase with many teams, the lack of types was a recurring issue. now i work in a SOA and face different coupling challenges.
But i much prefer this syntax to what RBS required.