Very neat but what an Albatross Python is, especially in the AI era. It is clearly the best language to choose for many applications given the network effects and the fact that AI can program it so effectively, but I really wish we weren't locked into it. So many better, more fun, more tight, languages out there.
And all this effort to eek out performance. Get off my lawn etc.
Having been around for a long time I liken it to PERL. Post-PERL it also looks a lot like Ruby. I remember everything being re-written in Ruby. Yet PERL still stands!
Anyway, Python is a nice language for small-ish (< 1000 lines or so) projects. It starts to get very unruly after that and without a type system of any kind your brain becomes the type system... and the compiler. MyPy tries it's best but it really isn't sufficient and requires developer buy-in...hard to get in a language so well designed for throw-away code.
Python 3's syntax is actually quite nice and you can write some very expressive code in it. My opinion, of course, but I also find it to be one of the "lowest common denominator" languages like Go. Python doesn't require much to get started and it's syntax and semantics are relatively easy for even a mediocre programmer to understand. Of course it has a terrible (mostly non-existent ABI) that relies on "consenting adults" as the contract and an awful package system. Yet another reason it's really only practical for (relatively) small projects.
Rarely is anything in Python about raw performance - imo. Of the things that are (NumPy, Pandas, various ML libraries) they call down to C handle most of it. For things that require true parallelism it's not uncommon to see `exec` calls to binaries. That being said in a lot of places (FastAPI based applications, etc) you can get quite a lot of perf out of Python before it becomes a problem.
However, what makes it super nice is how easy it is to hack something together in it. As it turns out most of ML is just hacking things together in a few files or a Jupyter notebook. What a perfect language for such purpose. This is not unlike PERL. I still remember all the random PERL scripts I hacked together for various tasks because it was so simple. It is no wonder it is as popular as it is.
Most of the time, Python's biggest issue isn't performance, it's the nightmare of trying to distribute it. If you want to merely run a python program you need to be educated in "python DevOps", or you'll get people gasping and saying "FFS, why don't you just create an env and activate it and pip install to it then make your own flipping shortcut to a script that activates that env and runs your code, you moron, Jeeeeeesus."
that the "activate it" part gets any airtime really pisses me off. that has all to do with bash and zero to do with python. the "activate" script should never have seen the light of day.
include a bin/run-python wrapper script in your project, and have that set environment variables and call the .venv/bin/python binary. done.
yes, i realise in replying to this comment i'm admitting that i'm part of the problem exactly described, but the "activate" script has caused more confusion in the long run than is worthwhile and the "running from a .venv/" directory could have been a much smaller problem instead of the wind-tunnel it has become.
That is obviously not what I meant by "solving it with bash" and well you know it.
First, one often needs to set PYTHONPATH etc, and this is best done near the point of execution, in a wrapper script and not wangling around in ~/.bash_profile where it gets forgotten, and is not project-specific.
Secondly, and more importantly, your suggestion assumes the venv lives in a fixed location. This is unlikely to be the case.[1] What is preferable is something which is independent of filesystem location. The bin/run-python script is able to find its location on the filesystem, and the location of the venv relative to it.
[1] You might have a custom python distribution with a bunch of modules installed into a well-known location and therefore using that for the python in your application is a reasonable solution, but that is not what we are talking about here.
I love programming in Scheme. I played with Nim recently and appreciated the type system. I also enjoy Common Lisp. Heck, I ever prefer Java! Haskell, Ocaml, Julia! I'd rather program in any of them.
I'm following them since their first mention in HN in 2023, particularly for Wasm support in compilation. Still not much output, unfortunately.
Very neat but what an Albatross Python is, especially in the AI era. It is clearly the best language to choose for many applications given the network effects and the fact that AI can program it so effectively, but I really wish we weren't locked into it. So many better, more fun, more tight, languages out there.
And all this effort to eek out performance. Get off my lawn etc.
Having been around for a long time I liken it to PERL. Post-PERL it also looks a lot like Ruby. I remember everything being re-written in Ruby. Yet PERL still stands!
Anyway, Python is a nice language for small-ish (< 1000 lines or so) projects. It starts to get very unruly after that and without a type system of any kind your brain becomes the type system... and the compiler. MyPy tries it's best but it really isn't sufficient and requires developer buy-in...hard to get in a language so well designed for throw-away code.
Python 3's syntax is actually quite nice and you can write some very expressive code in it. My opinion, of course, but I also find it to be one of the "lowest common denominator" languages like Go. Python doesn't require much to get started and it's syntax and semantics are relatively easy for even a mediocre programmer to understand. Of course it has a terrible (mostly non-existent ABI) that relies on "consenting adults" as the contract and an awful package system. Yet another reason it's really only practical for (relatively) small projects.
Rarely is anything in Python about raw performance - imo. Of the things that are (NumPy, Pandas, various ML libraries) they call down to C handle most of it. For things that require true parallelism it's not uncommon to see `exec` calls to binaries. That being said in a lot of places (FastAPI based applications, etc) you can get quite a lot of perf out of Python before it becomes a problem.
However, what makes it super nice is how easy it is to hack something together in it. As it turns out most of ML is just hacking things together in a few files or a Jupyter notebook. What a perfect language for such purpose. This is not unlike PERL. I still remember all the random PERL scripts I hacked together for various tasks because it was so simple. It is no wonder it is as popular as it is.
Most of the time, Python's biggest issue isn't performance, it's the nightmare of trying to distribute it. If you want to merely run a python program you need to be educated in "python DevOps", or you'll get people gasping and saying "FFS, why don't you just create an env and activate it and pip install to it then make your own flipping shortcut to a script that activates that env and runs your code, you moron, Jeeeeeesus."
PEP-723 solves this nicely.
https://peps.python.org/pep-0723/
https://news.ycombinator.com/item?id=43500124
Hopefully PEP-723 and uv will alleviate this.
that the "activate it" part gets any airtime really pisses me off. that has all to do with bash and zero to do with python. the "activate" script should never have seen the light of day.
include a bin/run-python wrapper script in your project, and have that set environment variables and call the .venv/bin/python binary. done.
yes, i realise in replying to this comment i'm admitting that i'm part of the problem exactly described, but the "activate" script has caused more confusion in the long run than is worthwhile and the "running from a .venv/" directory could have been a much smaller problem instead of the wind-tunnel it has become.
why not solve it with bash then, just put
#!/path/to/your/venv/bin/python
as first the line of your script, done/done
That is obviously not what I meant by "solving it with bash" and well you know it.
First, one often needs to set PYTHONPATH etc, and this is best done near the point of execution, in a wrapper script and not wangling around in ~/.bash_profile where it gets forgotten, and is not project-specific.
Secondly, and more importantly, your suggestion assumes the venv lives in a fixed location. This is unlikely to be the case.[1] What is preferable is something which is independent of filesystem location. The bin/run-python script is able to find its location on the filesystem, and the location of the venv relative to it.
[1] You might have a custom python distribution with a bunch of modules installed into a well-known location and therefore using that for the python in your application is a reasonable solution, but that is not what we are talking about here.
What's your personal favorite better, fun, tight language?
I love programming in Scheme. I played with Nim recently and appreciated the type system. I also enjoy Common Lisp. Heck, I ever prefer Java! Haskell, Ocaml, Julia! I'd rather program in any of them.
Kotlin
The repository appears to be active, https://github.com/lcompilers/lpython
How does this compare to GraalPy? Why create something new when GraalPy can already build native programs?