Ruby and the age of “I don’t care what type this variable is, it quacks like a duck!” is over and dead. Improvements to type systems have shown there is a better way to do software development.
Maybe, the cycle has happened before and maybe come back around again. Dynamic typing is really nice when most of your data looks like bags of strings. Compilers and tools just don’t add a lot when you’re passing around glorified blobs of stringy json-like stuff. Type gymnastics can eat a lot of time where you could otherwise be shipping something useful.
I would argue when you're passing around stringy JSON-like thingies is when typing is most useful :)
You're not going to misuse an API that takes a Person or Cart, but mixing up two hashes cause you used two different strings as keys can happen easily.
(I do think dynamic typing is mostly fine, but I do wish ruby had optional static typing with some nice syntax instead of RBS)
> You're not going to misuse an API that takes a Person or Cart, but mixing up two hashes cause you used two different strings as keys can happen easily.
This is more or less trivial to catch and fix, I'm just not sure a type system is worth it's weight for that kind of case.
I’m really excited about Sorbet getting behind the new RBS-inline comment syntax and the prospect of both runtime and static analysis as optional tools when needed.
I haven't really felt a need for static typing in my job's Rails app (small team, and I've been working in this codebase a really long time) but I think LLMs can be a huge help for automating the type gymnastics.
Typescript is literally a language describing what the quack “sounds like” so you can attempt to ensure any particular variable makes those kinds of quacks. Typescript doesn’t care that it also quacks like a dog.
Plus, Ruby has lots of easy ways for you to check typing, if you want to.