> why bother with an interpreted language in the first place
+1
As a person who uses Python for 12 years professionally I usually try to avoid it as much as I can. When you have a Python problem you usually have a C, C++, Rust, libc, arch problem that you do not realise. Most of the useful parts of Python are written in C, C++, Fortran, Rust so when you try to deploy it some less frequently used platform it can burst into flames the worst kind of ways. You can try to deploy the AWS Lambda / Python 3.9 and see the lolz. I have spent more hours on trying to get some Python lib work on a platform than learning Rust.
I think interpreted languages are a dead end especially with bad practices. I make my living writing Python but it is a misery every direction. It is not an accident that Rust is the most loved language continuously because it just works. Anything I try to do in it works as expected and I am not walking on a mine field.
Let me give you a simple example how Python can surprise you. Lets create an app in Python that uses a lib called X. You build your project and everything works locally, unit tests are ok, integration tests too and so on. Now deploy this code to AWS Lambda (not your choice, employer decided to go with that). You package everything up on a Linux that matches the architecture of the target (lets say X64). If you are not familiar with setting the target Python version with pip (and most documentation does not mention that for Lambda) you deploy your code and try to invoke it. Fail. You have X.311.so in your deployment package and Lambda tries to load X.39.so. Now you need to figure out how to set the version or have a build env that matches the CPU AND the Python version with the target system.
I could continue this rabbit hole for some more but the point is that you can't talk about Python alone, you need to pull in the Cartesian product of libc, libXX, C, C++, Fortrant, all the compilers for these, cpu architectures and Python versions. On a lucky they you might have a working system.
With Rust everything just worked the first time we tried to use it. I could not believe it how easy it was to put out a working system at the first try. It only beats Python by an order of magnitude in terms of performance but the amount of effort it took us to deploy it was also much less.
> Most of the useful parts of Python are written in C, C++, Fortran, Rust so when you try to deploy it some less frequently used platform it can burst into flames the worst kind of ways.
You can always write it in python.
This is the attitude which prevails those days. C is to blame because someone wrote Python in C.
What stops those people implementing the standard POSIX in rust or python ? Or even the X windows system or (for clairvoyants) the Wayland in Python or Rust ?
Or even better, they can make their own OS written in these languages (and even call it MULTICS).
Except you can't. Python has horrendous performance. You can write it in C and pretend it is Python.
> What stops those people implementing the standard POSIX in rust or python ? Or even the X windows system or (for clairvoyants) the Wayland in Python or Rust ?
> Or even better, they can make their own OS written in these languages (and even call it MULTICS).
This is exactly what is happening in the industry with really nice progress. We are entering the era when bad practices and subpar performance is not acceptable anymore. I am really hoping that Rust takes over devops and data at the very least. It started to enter the IoT space and some OS development (Linux supports it).
I am really hoping that this trend continuous and we start to see more an more device drivers in Rust and other safety and security critical systems.
As far as Python goes, I would be totally happy if Python would become the interpreted language that I could use on the top of Rust and I had to deal with only Rust problems.
+1
As a person who uses Python for 12 years professionally I usually try to avoid it as much as I can. When you have a Python problem you usually have a C, C++, Rust, libc, arch problem that you do not realise. Most of the useful parts of Python are written in C, C++, Fortran, Rust so when you try to deploy it some less frequently used platform it can burst into flames the worst kind of ways. You can try to deploy the AWS Lambda / Python 3.9 and see the lolz. I have spent more hours on trying to get some Python lib work on a platform than learning Rust.
I think interpreted languages are a dead end especially with bad practices. I make my living writing Python but it is a misery every direction. It is not an accident that Rust is the most loved language continuously because it just works. Anything I try to do in it works as expected and I am not walking on a mine field.
Let me give you a simple example how Python can surprise you. Lets create an app in Python that uses a lib called X. You build your project and everything works locally, unit tests are ok, integration tests too and so on. Now deploy this code to AWS Lambda (not your choice, employer decided to go with that). You package everything up on a Linux that matches the architecture of the target (lets say X64). If you are not familiar with setting the target Python version with pip (and most documentation does not mention that for Lambda) you deploy your code and try to invoke it. Fail. You have X.311.so in your deployment package and Lambda tries to load X.39.so. Now you need to figure out how to set the version or have a build env that matches the CPU AND the Python version with the target system.
I could continue this rabbit hole for some more but the point is that you can't talk about Python alone, you need to pull in the Cartesian product of libc, libXX, C, C++, Fortrant, all the compilers for these, cpu architectures and Python versions. On a lucky they you might have a working system.
With Rust everything just worked the first time we tried to use it. I could not believe it how easy it was to put out a working system at the first try. It only beats Python by an order of magnitude in terms of performance but the amount of effort it took us to deploy it was also much less.