| Interestingly there are still areas where most people seem to prefer dynamic typing: service APIs. JSON everywhere. Is it because JSON is actually better, or is it because we don't yet have good enough tools for schema-driven APIs The main issue is that static typing is a global property of a program, and big distributed systems don't have such global properties. Each part can be upgraded independently, at any time. In general, you don't own both sides of the wire. People who have worked at Google are used to owning both sides of the wire :) (I also think the model of the data center as a single computer stopped scaling, and that's why it's so hard to write software there these days) The argument I usually make is: Why isn't the entire Internet statically typed? Why don't we have statically typed HTTP and SMTP and IRC and XMPP ? If you admit there's a problem there, then there are also problems with static typing in the areas where people use JSON. --- Dynamic typing is basically for when static typing stops scaling / runs out of steam. I wrote a long post about this - A Sketch of the Biggest Idea in Software Architecture, i.e. about software composition at runtime, not compile time: https://www.oilshell.org/blog/2022/03/backlog-arch.html Also, static typing doesn't scale to the code even on a SINGLE machine, on either Windows (COM and successors) or Linux (Debian-style ABI compatibility, and shell-style composition) https://lobste.rs/s/sqtnxf/shells_are_two_things#c_pa4wqo Some people scratched their heads at that argument, but I would say it's only irrelevant if you don't care if your system works when it's deployed. If all you want is for the IDE to say green and commit your code, then you can just lean on static typing. But if you care the problem from end-to-end, you should also care about dynamic typing and runtime software composition :) The other argument I make is that SREs are responsible for all the problems that escaped the static type system, and ~10 years ago SREs started making as much or more money than SWEs. So that is a lot of problems. The problems that static types catch aren't the most important ones; they're just the ones that affect certain people's jobs. --- Protobufs do a pretty good job of evolution, but I've noticed it takes awhile for people to understand that field presence is dynamic, not static. They want their Maybe<> type, but that kind of static typing simply doesn't work in distributed systems. I'd say better tools could help in some ways, but you still have the fundamental problem that even if I go and download Github's or Stripe's schema from their codebase and statically link it into my code, I don't control when they deploy their systems. They can literally update it in the FUTURE, and static checks fundamentally can't handle that -- only dynamic checks can. |
> They can literally update it in the FUTURE, and static checks fundamentally can't handle that -- only dynamic checks can.
You're not wrong, but you are underselling what reasonably disciplined adherents to a static regime can use to their advantage.
----
My favorite commentary (in favor of your position of what static can't do*) include:
- some remarks Gilad Bracha once made on some podcast (might've been Software Engineering Radio) about how hardware at base is not static, which feels somewhat counterintuitive when low high-level languages like C are in the same room suggesting that the truth is otherwise
- Lars Bak giving an interview about V8 at Microsoft to Erik Meijer and Charles Torre(?) where Lars breaks the latter's brain by pointing out that even if JS hadn't won and you were dealing with a purportedly better static language like C# compiled down to CIL, then the engine would still apply the same treatment to the payload it received, insofar as performing "inefficient" dynamic validation
* which happens to be my position, too, to be clear