[lukehutch]

How about instead aiming for 1000x as fast, so that it's as fast as a statically-typed language? (Google's pure Python Protobuf implementation is literally 1000x slower than their Python front-end that wraps the C++ Protobuf library...)

Oh wait, achieving native speed is close to impossible for a dynamically-typed language.

[coldtea]

>Oh wait, achieving native speed is close to impossible for a dynamically-typed language.

It's actually quite possible, and depends on the scenario.

A dynamically-typed language can analyse actual runtime type use and specialize function calls with a JIT, for example. It's also possible (and there's work in this area) to keep the specializations around for quick startup in the next runs... (and of course, drop them if they no longer hold).

That's how Javascript is much closer to native than Python - in some cases just 2-3 times slower than C. Lisp did very well too (better than more than a few static languages).

And that's with the extreme meta-programming / reflective behavior (which both Python and Javascript have). With less such, one could make a dynamic typing language that can be trivially JITed to run very close to native.

[liberalbias998]

I agree: here are some good examples of fast interactive dynamic languages

- Strongtalk from the 1990s

- Pharo Smalltalk (Cog VM)

Also worth looking at

- Chez Scheme

And

- JavaScript in every popular modern browser.

And

- Luajit

[elcritch]

An interesting thing about all those examples are that they’re fairly streamlined languages making it easier to write good accelerators. Even JS only has one prototype system and lots of functions. All in contrast to Python which has a quite complex runtime and accidental complexity in the language design details.

[Asraelite]

> And that's with the extreme meta-programming / reflective behavior (which both Python and Javascript have)

It would be interesting to see what kinds of speeds a scripting language that is actually well suited for JIT would be able to achieve if it had the same tremendous amount of effort put into optimizing it that Javascript has received.

[turbinerneiter]

Lisp is dynamically typed and can reach C-like speeds.

Python is something like 40 times slower than C, lisp gets much closer with something like 4 times slower (all of this heavily depends on what you are doing obviously, so just rough ballparks here).

[TylerE]

Why bother when nim already exists?

[coldtea]

Because it's a niche language with a very small ecosystem.

Whereas Python has tons of libraries, millions of programmers, tons of support, tons of documentation and books, and billions of lines of existing codebases...

[dvfjsdhgfv]

> Because it's a niche language with a very small ecosystem.

Python was like that once, too. Now we have the necessary experience to understand what are crucial aspects of the language that are missing but are extremely difficult to change post-factum, such as removing the GIL. Nim has no such constraints, and while building the ecosystem takes time, I have no doubts it will progress smoothly as Nim is such a pleasure to use. Even for such a young language I feel we're already in a good shape: https://github.com/nim-lang/Nim/wiki/Curated-Packages.

[kuratkull]

Nim is actually really good and a pleasure to use. But Python, sadly, dominates the market space and there's a lot of existing code that would get a minor boost. And as Python plans to be 5x faster in a few years, so it's part of that process.

[turbinerneiter]

Nim doesn't make existing python vide bases faster.

Also, do you really think the Python team should just give up on performance just because faster languages exist?

Should Tesla stop building cars as soon as someone builds a faster car than them?

[planetis]

Actually it is possible, Nim compiles to C and is a viable alternative to CPython.

nimpy https://github.com/yglukhov/nimpy PyGotham talk: https://www.youtube.com/watch?v=IVgNVJdizHg another blog post: https://robert-mcdermott.gitlab.io/posts/speeding-up-python-...

[turbinerneiter]

This doesn't make existing python code bases faster. You have to rewrite in nim.

[planetis]

Yeah (rewrite) just the hotpaths like you would with Cython. Also there is https://github.com/Pebaz/Nimporter which makes it easier.

[dvfjsdhgfv]

I believe OP means new code bases; rewriting the existing ones obviously makes sense only in specific cases where performance is a key factor.

[prirun]

Go to the Nim forums and check out some posts from people who wish Nim was more like Python. In the Nim tutorials, they appear to be closely related, so when new users encounter Nim, a port from Python code to Nim seems reasonable. If you post anything like this on the forums, get ready for some hate.

Nim wants to be its own thing, and posters are quick to point out that Nim isn't Python, never was intended to be, and never will be. That's what the DFL wants, which is fine. But IMO, creating a language that is closely-related to Python, arguably one of the world's most popular languages, and allows / encourages porting large Python codebases, seems like a pretty worth goal. Now that Nim has already made a lot of decisions to make that difficult, it can't pivot to that goal without breaking all the existing Nim code. Too bad: seems like a big opportunity lost to me.

[planetis]

> creating a language that is closely-related to Python, arguably one of the world's most popular languages, and allows / encourages porting large Python codebases, seems like a pretty worth goal.

well they do state "copying bad design is not good design" in the main page. Actually porting Python code to Nim is not that difficult especially when people care enough to create pages like: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

[sideshowb]

Is dynamic typing really what kills Python's speed? Or even allocation and gc? I always kinda assumed it was doing dictionary lookups for variable access that really took time.

[jakobnissen]

It's 100 small things, each which were accepted because Python was already so slow, it didn't make a difference. Look at the past graveyard of failed attempts to speed up Python. Pypy and Numba are probably the best examples, but neither are very useful.

I think it's best to accept Python is just slow, and to use another language.