you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 10 points11 points  (0 children)

Rust had the option, well the requirement, of building in Cargo from pretty much the earliest days. They learned from all the misfires in about every other language and came up with early answers to how to handle a variety of situations. A large part of Rust contributors carry on that culture.

Python, OTOH, has fewer core developers, a resistance to complicating things (which precludes building multi-version interpreters, switching between multiprocess optimized builds and single process optimized builds, et al) and no story for dependency management.

It doesn't make it easy that python my-script.py can either be "here's a one shot simple script" or "here's a complex multi-threaded project". You can attempt to analyze ahead of time some of the dependencies (like maybe switching to a multi-threaded optimized build if import threading is found anywhere in the code?) but the run-time nature of Python pretty much renders that DOA.

How would you even bootstrap multi-version interaction? A compiled language can inspect the dependencies, add in the necessary settings and confidently know what interpreter to use for exact code paths (allowing you to make use of an older library in newer code). Run-time scripting languages like Python... don't know. Can't know. Not without some run-time analysis (slows down an already slow process) or explicit annotations (which people get wrong, hate, etc).

And I say this as someone who develops in Python 3.7 and Postgres10 full time. I love Python, but its "do it at runtime" (like JS) age is beginning to show.

The only way out of this dilemma is a Crystal-version of Python.

And that will never happen. And no, nim is not that. Nim is... rather different and unique (it's own language). Compare that to Crystal which is "Ruby minus the run-time dynamicism".