Perhaps the post title could use a tweak
The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.
Perl 6?
What languages are you thinking of specifically when you mention better thought out ones?
C# is strongly/statically typed, compiled, and quite fast (after the vm has started), whereas python is weakly/dynamically typed, interpreted, and generally slow as fuck. Those are two fundamentally different languages, how could it possibly be a coke/pepsi situation?
I think python is fantastic for certain use cases: gluing other tools together (like LAPACK or other ancient libraries), system automation, prototyping, exploitation (I think pretty much all of us were working on stealmybitcoin in python), and exploratory data analysis.
The problems arise when people try to write, say, gigantic GUI applications in python, or really anything with CPU-bound workloads. Part of being an engineer is using the right tool for the right job. Python is the wrong tool for lots of jobs. That shouldn't be a controversial statement.
What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?
Apparently you can't be a senior dev unless you "just here to deliver"
It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.
Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).
No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.
"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.
Go is a lot more elegant and well designed, it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..
I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.
Cross platform interpreter.
NumPy and SciPy really set the stage.
But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.
The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.
- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician
- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS
Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.
Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.
It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.
It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.
It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.
Pylance + Pyrefly: bring your preferred type checker to Visual Studio Code
https://devblogs.microsoft.com/python/announcing-tsp/
Pyrefly + Pylance Integration in VS Code
Why don't you spend your resources on F# instead of this nonsense?
- https://docs.basedpyright.com/v1.40.2/type-server/
- https://github.com/microsoft/pylance-release/discussions/718...
Ty (the type checker maintained by astral) however will apparently support the TSP: https://github.com/astral-sh/ruff/discussions/23432