Dynamic Languages Strike Back (2008)
steve-yegge.blogspot.com
steve-yegge.blogspot.com
Not (only) because that's faster to run, but because it's faster to change while still remaining somewhat working correctly. And the current crop of compilers not only can produce stunningly fast code, but also awe-inspiringly great error messages that put the 90's and oughties' cryptic error messages to shame. Try that with a dynamic language!
I think it’s interesting how static and dynamic languages have grown closer together since this was done. I’m not sure there’s really all that much to argue about anymore. Your static languages tend to have many of the features people like about dynamic languages and vice-versa, though of course that depends on the specific language.
That said, I agree with the rest of your comment - static types for correctness and static types for performance are two different goals, and most gradually typed systems work towards the former and not the matter. (And more to the point: adding types alone is not sufficient for the latter. Python is not slow because it has no types, Python is slow because it isn't designed to be fast, and changing that now would require a lot of fundamental changes to the language and ecosystem, of which types would be one of the least relevant.)
What I’ve heard from people who work on performance is, the type hints can provide benefits potentially, but just not relatively as useful as other runtime improvements. The development effort is simply better placed elsewhere.
It is valid to critique gradually typed systems like Python for not improving performance.
But in a dynamic language like python your options are limited.
Consider:
def add(a: int, b: int) -> int: return a + b
assert add(1,2) == 3
a, b = random.choice((3, 4), ("foo", "bar"))
assert add(a,b) in (7, "foobar")
In the first call we use ints and are golden. In the second we get ints or strings and we cannot know which until runtime.
So if we are going to use type information for speed improvements how should we proceed?
Some ideas.
1. Generate special purpose small (32 or 64 bit) integer version in a custom type aware bytecode format or ASM and a common version of the function. Use run-time typechecks to decide which one to use.
We generate two versions of the bytecode instead of one we also run some optimizations on the integer version to actually get a speedup when we call it.
To do the integer optimization we probably need a new special type aware bytecode format. (or just compile to assembly directly) To get advantage over the interpretor where everything including integers are objects.
When we call 'add' we just check the type send the values to our new bytecode format and bam faster add (possibly faster anyways).
Having two versions of the function will take extra memory and increase startup latency (during compilation to bytecode)
In some cases we could directly call the integer version of add like in the first call we know we are working with ints, in the second call we cannot know until the type check if we are dealing with ints or strings.
Will all of this be worth it? We use extra memory, slower startup time and an extra typcheck when we are not 100% clear on the types.
For hot code it could be worth but we do not know what code is hot and what is cold until we run the program. We could tell the compiler what is hot and what's not like 'numba' does, but then we are going beyond typing.
So why does python not so this? Well for a start it's very unclear that we will gain performance from this extra compilation / bytecode swapping but it will slow down startup. It will also be a massive change to the internals of the standard interpretor and need tons on man hours supporting this beast.
At a first glance it does not look that hard to do this extra compilation but the add function is very simple. What about more complex code that calls unknown methods that have not been defined yet possibly even loaded at very late at runtime. Will the ASM layer help or hinder when you need to go back and forth between the interpretor and optimized code? The interpretor really does not have enough information to make intelligent decision on this.
2. We could go the route of static languages. Compile only a special case integer version.
Assuming that we always use the function correctly this could be fast.
But this would be extremely unsafe in a dynamic language, if we don't have an integer but do integer additions on the objects internals anything could happenn.
Now if you have full static typing you can do this, really you should do exactly this. It is safe to assume that we are calling the function with the correct types, since it's enforced at the language level. Which leads us to do all kinds of optimizations that the dynamic nature of python prevents.
3. Just use a JIT like 'pypy'.
A JIT would do basically option 1 but only after hot code paths have been identified. Startup time is less of an issue since we delay compilation untill we are sure we need it (or fairly sure at least).
Type hinting could help guide the JIT if you using fairly specific types such as 'int32' instead of int to highlight that we are just interested in small numbers. But the information might also be missleading so it might opt out of using it altogether.
-------------------------------
Cpython does not do (1) since its not clear that you get any substantial speedup and startup latency is a big deal. Does not do (2) since its super unsafe. And it's not a JIT (3).
Yes, you can still do dynamic typing. But I'd argue that using `dyn Any` you can do so in Rust, which is a statically typed language if I ever saw one.
Otherwise I completely agree about the languages growing closer together.
Dyn Any is precisely no use here. If it's a simple on/off thing, you can maybe hack up some macro in rust, but that's a completely different (and not very well designed) language, will require you to manually modify all the source you want to instrument, and also if you want do dynamically alter at runtime what gets instrumented based you're out of luck.
Basically, there can be a lot of value in sporadically leveraging the dynamic nature of python or similar languages, even if you use it as a poor man's statically typed language > 99% of the time.
That's a really good observation. Many people ask why Python is the lingua franca of ML. It's a glue language that allows you to prototype quickly and use low-level libraries like numpy for matrix calculations, etc.
I wish Python type hints were taken more seriously. It's crazy that you can type them in function definitions but then Python completely ignores them. mypy does a much better job at that, but that's not the Python most people use.
Its a lot more than a glue language. Its just the right amount of high level abstraction with easy extensibility to make it applicable to most applications out there.
Even for things that are performance sensitive, extra containers/instances are cheaper than developers.
We're seeing a swing to what I call "pragmatically typed" languages: those with extensive type inference and possible escape hatches.
There are highly dynamic languages like Lisp that have implementations that have generated “stunningly fast code” for ages.
Sure a handful of people use Rust now and Swift and Go now, but I think you missed the whole point of the fine article
But the key thing is that none of this is for performance purposes. Which is kind of the whole point of this talk: speed isn't everything, and the productivity of languages without types outweighs that of languages with types. But it turns out that types are really useful even without any sort of performance benefit, hence why a lot of languages are turning back to typing code without using those types at runtime at all.
Or similarly, he makes a point about how it's often possible to statically analyse dynamic languages, which is true, but it turns out that it's still so much easier to analyse statically typed languages that adding types back in often makes sense. If you read library documentation for packages using gradual typing, this is often one of the things they specifically mention as a reason for using their library with static types instead of without.
The point, as I understood it, was that you don't need static types to still get lots of cool things (performance, analysis, etc). Which is stuff I don't disagree with. But the quality of those things with (well-designed) static languages is still so much higher than it is in dynamic languages, which is why so many languages are now trying to support both modes.
TypeScript isn't faster than JavaScript, it doesn't even change it's emit based on types - which are completely erased.
Similarly, Python with type annotations is not a statically typed language either.
Dynamic languages increase productivity, static languages learn from dynamic languages & find ways to statically verify the previously thought dynamic patterns.
A lot of ML startup use Python in production. OpenAI uses Flask to power their API for ChatGPT and their other models. Almost every AI startup uses Python in production for more than their ML/AI stack.
Python, Javascript, PHP, and Ruby are still very popular languages today. More popular than Typescript, Rust, Swift and pretty much every typed language outside Java, Go, C and C++.
I think, in general, we've seen the hype cycle shift from static to dynamic to static, and we see that e.g. startups and otherwise highly opinionated people who care about such things maybe change their preferences (or simply new people entering the field with new preferences), but...
the millions of people writing Java code didn't go away when Ruby and later Node were all the rage, and all the PHP jobs also still exist.
Trends come and go, but dynamic and static typing have coexisted since forever. LISP is the second oldest language and if that's too niche, Smalltalk was decently popular for a while.
I also agree though that modern statically typed languages are much better than e.g. Java used to be.
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.)
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.
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
The error checking nature of compilers was never a real pain point. It's a question of if you want pain now or later.
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.
I can fault Ruby for many things, but Bundler is easy to use and just works (except in the case of C bindings, but I don't think that's in the scope of Bundler to fix), and from what I hear, cargo should be similar.
[0] Although this is also an ecosystem problem; in e.g. Ruby, libraries specify version ranges for subdependencies, and then Bundler will try to resolve all version ranges, and report an error if there's no way to resolve it. Usually, this works quite well. A Java library A will just specify a particular version of library B, you have no guarantee that the version of B that you get when you add A to your build is the same one. There are various solutions to this, such as BOMs, but if the library you use isn't in a BOM, you're out of luck. In any case, this is not a theoretical problem, I've spent countless hours trying to debug problems with conflicting dependency versions causing errors at runtime because certain classes or methods didn't exist.
I feel like you should be more specific instead of replying with a one-liner to a list of very specific complaints.