|
|
|
|
|
|
by ekidd
777 days ago
|
|
|
I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing: - A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment. - The ability to change an API and immediately see all the affected code. This affects refactoring speed when making big cleanups. Massive updates I could do in a few hours in Rust might take 2 weeks on a big Rails project. - Team-wide clarity on exactly what goes into key data structures. Can something be null? Does it allow numbers, or only strings? Etc. With two developers and a small code base, you can keep most of this information in your head. And Rails is still unmatched for terse, clear code, plus off-the-shelf modules for many common tasks. I'm not even sure that Ruby could be retrofitted with a really worthwhile type system, to be honest. JavaScript already required a lot of black magic, and in some ways, Ruby is even more dynamic. So perhaps Ruby is better left as-is, even if that makes it a poorer choice for projects that would benefit from static typing. |
|
|
Similar points between your comment and the other reply. Still I worked with Java in the past and Ruby has been a liberation for me. It allows me to simpler, cleaner and less complex to write my code.
I work on one of the largest Rails apps and the added typing is usually more of a burden than anything - sure could be the implementation of typing which is harder for Ruby than let's say JS (to your point)
Still I don't mind others wanting to write typed code and finding more positives to it than I do - I just still am not convinced that statically typed is ever objectively better than dynamic and it stays of subjective nature.
TLDR: imho the quality problem of most large code bases is not due to dynamic typing but due to many other factors that lead to low quality code