> It’s mostly about the strong typing for me. Nothing revolutionary about that idea, but it’s just as true on the client as on the server: having the compiler type-check your code makes it much quicker to get complex, sophisticated systems up and running.
I used to believe that this was obviously true. Then I went from doing a lot of programming in JS where even with a large codebase, I could see the code fail in seconds to programming in Scala where type errors would not always appear in the editor, but you'd have to do a compile step that takes ages to actually see them.
Now I'm much less sure about the benefits of typing. What is actually useful is fast failure and short iteration cycles. Seeing the errors as you write is the fastest failure there is, but if I have to run a 30 second build to see a type error, that is much worse than dynamic types but seeing the error in less than a second.
Its true that carefully thought about types can catch errors you might not see immediately, but you can fix this to some extent with putting effort into making sure your code fails fast, and adding unit tests and while this doesn't give you proof-level guarantees, for most practical work, with discipline, it's good enough (even if emotionally unsatisfying).
Maybe one day I'll find a system that lets me encode constraints into the type system and have it actually tell me about violations quickly, and I'll happily leave dynamic land behind (for most things), but I've come to the conclusion that arguing about type systems misses the point, and the point is that failing fast is better than failing late. Within a single environment, failing at application startup is better than failing at an arbitrary point in the future. Failing at compile time is better than failing at startup. Failing at edit time is better than failing at compile time. But if your compile time is slower than my runtime, you're losing.