[kentonv]

I remember this post from the time and I'm glad we've come so far since then.

It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools. You'd write code for a while, then you'd run the compiler, and UGH there's all these errors to go back through and fix.

Now that my IDE highlights the errors as I go, not to mention has good auto-complete and jump-to-definition, I am much more productive in a statically-typed language than a dynamic one.

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 (e.g. Protobuf, Cap'n Proto, etc.)? If we had those tools, would schema-driven APIs be widely seen as being more productive? (I suspect so but I am perhaps biased.)

[shellac]

> It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools.

Java IDEs were certainly highlighting errors, auto-completing, refactoring etc in 2008. Admittedly IntelliJ (the most impressive one) didn't have a free version then.

[howinteresting]

The problem with Java is that it is the most OOP language to ever exist, and OOP is an incoherent way to write production systems. Oh you've overridden a method in a subclass, ok. Who is responsible for calling whom? Which methods get to enforce invariants and which methods get to assume them? Documentation is an insufficient answer.

[maccard]

Eclipse was available and free long before 2008. C++ had had visual studio, as has c# for longer than that too.

[kentonv]

Yes, but outside of Java developers a lot of people didn't understand the power of this yet.

[dehrmann]

> You'd ~~write code for a while, then you'd run the compiler,~~ run code, and UGH there's all these errors to go back through and fix.

The error checking nature of compilers was never a real pain point. It's a question of if you want pain now or later.

[make3]

Python is everywhere for ML, Javascript & it's dialects are everywhere for web etc., so dynamic languages are definitely everywhere now

[zerodensity]

JSON is better than xml which it replaced. It's now such a defacto standard that if you make an API without json it will just be a hassle for your api users. Doesn't really matter if your encoding format is better or not.

You can still have schemas in the code through. We use alot of pydantic at work for this. You have your data schema class that is statically typed which you interact with and decide/encode it to json in the background.

All services expose an api to get JSON schemas from the apis so you can automatically generate the remote types used by other services when they change.

Using schemas for remote services has made life simpler for us so I would say schemas are a huge win. Not supporting JSON is not something I see happening anytime soon though, multiple parallel encodings based on schemas might be a possibility though.

[chubot]

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.

[cxr]

> 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.

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