←back to thread

333 points steveklabnik | 3 comments | | HN request time: 0.649s | source
Show context
gurgeous ◴[] No.45035053[source]
I am so excited about this!! Ruby tooling is already pretty good, but we can do better. I will try to contribute. Now we just need types
replies(2): >>45035149 #>>45040884 #
dismalaf ◴[] No.45035149[source]
Please no types... They're worse than pointless for a dynamically typed language.
replies(5): >>45035235 #>>45035294 #>>45035575 #>>45035612 #>>45040464 #
1. jameslk ◴[] No.45035294[source]
Static analysis through type hints brings plenty of benefits to a dynamic language, such as helping to eliminate bugs at runtime (albeit not perfectly) and making it easier to grok a codebase. It’s a trade off and Ruby is as dynamic as it gets. But there is a point to it
replies(1): >>45036528 #
2. phoronixrly ◴[] No.45036528[source]
My beautiful experience with sorbet: Yeah, ducktyping? We don't do that here.

Depending on a library that uses ducktyping (like any sane library following the Ruby conventions)? Good luck writing a wrapper for it. Or just disable type checking.

This goes so much against the Ruby vibe that I advise you to just go and use Rust instead if you hate Ruby that much that you want to butcher it with types.

replies(1): >>45041025 #
3. jameslk ◴[] No.45041025[source]
Sorbet has its flaws. I didn’t like it either. Having used TypeScript extensively, there is a way to do it right and a way to do it wrong. I’d classify TypeScript as the ideal way to introduce static types into a very dynamic language, given its extensive flexibility to handle dynamic features in a language (e.g. smart type inference, ‘is’ keyword, very flexible generics). Sorbet doesn’t have a lot of those features

Ruby has a strong history and tradition of TDD/unit testing. This is partially a crutch for its lack of static type analysis. Ultimately checking for bugs before running code is very useful