[llogiq]

Yeah, that one hasn't aged too well. We've all seen the backswing to statically typed languages. Yes, some of them (e.g. typescript) run on top of dynamic langs, or allow for VMs (hi, WASM!). Why? Because ironically the same famed flexibility that makes it oh so easy to whip up a prototype is biting us in the ass when it comes to make a production-grade piece of software while staying on top of the ever changing requirements. So while we have a lot of python in ML (where most things haven't left prototyping stage), a lot of code nowadays is written in languages like Rust, TypeScript, Swift and others.

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!

[jmull]

IMO, it hardly seems useful to consider a dynamic language with statically checkable type annotations to be a static 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.

[frou_dh]

The situation with CPython where you can type-annotate and statically type-check your code to the hilt and that confers no runtime performance benefit is so tragic.

[zerodensity]

Well the idea is orthogonal to performance really. Static types makes it simpler to automatically spot issues in the "static" portion of the code. It's also very useful for metaprogramming since types are included at runtime. Additionally it gives better documentation for free. Gradual typing wont be able to make interpretors faster though. A jit compiler could in theory take advantage of it but since CPython is not a JIT it will not.

[MrJohz]

As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour. For example, at runtime, a type might typically be narrower than the compile time declaration. Also, with most gradually typed languages, the types aren't enforced at runtime, and the type system can often be circumvented, which means basing optimisations on the declared type hints will send the optimiser down useless rabbit holes.

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

[uranusjr]

> As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour.

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.

[frou_dh]

Put it like this... programmer in language X expends the effort to write a well-typed codebase and is rewarded with both reliability and performance. Programmer in Python expends the effort to write a well-typed codebase and only receives half the reward. Kinda tragic you have to admit.

[howinteresting]

Static types are at a ~45 degree angle to performance, not orthogonal. Static types are essential for optimizing code and data layout, which contribute hugely to performance.

It is valid to critique gradually typed systems like Python for not improving performance.

[zerodensity]

In static languages sure types are very important for 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).

[llogiq]

Well, if the programmer writes the type annotation to actually have their code checked, how would a gradually typed language differ in practice from a static language?

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.

[patrec]

Here's a practical example: you have your beautiful statically typed check code in python. But still, something doesn't work, or works but is too slow. So you write, in less than a page of code, some function to instrument bits of code you care about to collect and display some relevant info as the thing is running.

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.

[lelanthran]

Optional typing is closer to dynamically typed than to statically typed.

[krupan]

What are you even talking about? The amount of JavaScript and Python in the world has probably grown exponentially since that article was written. The article points out that there are ways to make dynamic languages faster and JavaScript interpreters have indeed been made blazingly fast since this article.

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

[MrJohz]

Except both Javascript and Python - along with a bunch of other dynamic languages such as Ruby and Elixir - are adopting gradual typing into the ecosystem. In both Javascript and Python, most of the major libraries and frameworks are either typed directly, or provide typings. It's difficult to get a good overview of the ecosystem on the closed source side of things, but most of the people I talk to in the Javascript world are moving pretty quickly towards Typescript, or have done it already.

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.

[behnamoh]

> So while we have a lot of python in ML (where most things haven't left prototyping stage)...

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.

[ActorNightly]

> It's a glue language

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.

[troupo]

> We've all seen the backswing to statically typed languages.

We're seeing a swing to what I call "pragmatically typed" languages: those with extensive type inference and possible escape hatches.

[novok]

IMO I miss static typing at around the 500 line mark especially when making programs. I was surprised it was that fast.

[spankalee]

TypeScript is not a statically typed language. It's more like a type-aware linter for a dynamic language. It doesn't "run on" JavaScript, it more-or-less is JavaScript. Any runtime helpers that TypeScript includes are merely polyfills for JavaScript features and compiling to the esnext target includes no runtime code at all.

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.

[impulser_]

> So while we have a lot of python in ML (where most things haven't left prototyping stage)

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

[Tainnor]

> We've all seen the backswing to statically typed languages.

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.

[LispSporks22]

> current crop of compilers not only can produce stunningly fast code

There are highly dynamic languages like Lisp that have implementations that have generated “stunningly fast code” for ages.

[marcelr]

Give it another 10 years, it'll swing back.

Dynamic languages increase productivity, static languages learn from dynamic languages & find ways to statically verify the previously thought dynamic patterns.