My Switch Away From Python
Table Of Contents
- From Beginner to Professional
Some context for this article, python was one of the first languages I learned and with which I became comfortable using. The incredible part about python, in my mind, is how accessible it makes programming to the world in comparison to other beginner languages like java. With that being said, the longer I've been in the software development sphere, the more I've started running into issues with using python in projects.
From Beginner to Professional
Undeniably, Python has made huge steps in programming accessibility for not just the average computer science student, like myself, but to everyone around the world. It's given people the freedom to focus on being creative and not thinking about what's going on behind the scenes. And this accessibility is coming from a real honest-to-god programming language with batteries included, not some toy language like MIT's scratch or whatever. Machine Learning is probably the biggest example of how much a field can benefit from having an accessible programming language behind it. If ML was still all done with something like C/C++ rather than in python atop numpy/tensorflow/matplotlib then you could make the argument that ML wouldn't have risen to popularity like it has. Looking at how the future is moving, I see two things that are sparking the end for python: the invention of the newer compiled languages (Swift, Golang, Rust) and the movement to NoCode.
def f(x: int): int:
y: int = 5
return x + y
def int f(int x):
cdef int y = 5
return x + y
So it's kind of a mess to look at and deal with. Going forward, it really seems that Mypy type annotations are really cool but they'll never replace a really good statically typed language. Many of the new modern languages that I mentioned earlier like Swift, Go, and Rust are all statically typed, but the compiler is smart enough to infer the types of variables.
let x = 42 // x is inferred to be an Int
This is super accessible and the static type system doesn't get in the way unless you try and do something stupid.
Client Side Deployment
Even if there was a good framework, it would have to address deployment. I recently tried deploying a PyQt app to some windows machines and it sucked. My team even tried compiling to an exe and that was a whole-ass experience. Client side deployment for interpreted languages seems to always have a few issues and it seems to be especially prevalent with python. The operating system provided python interpreter always seems to cause problems without fail and particularly with beginners who aren't used/don't know how to set up a virtual environment for python. Going along with that, I've always found python dependencies to also be a huge mess when working with/deploying python code with
setup.py being not very robust to errors and difficult to understand for beginners compared to other languages (rust's cargo being one in particular that I like). Fortunately, there are a few projects in the community that make dependency management easier like
poetry . Both tools make things pretty straight forward since
pipenvfeels like node's
npm while poetry feels like rust's
Server Side Deployment
Back in dinosaur times, languages like C were running into an issue: they weren't as cross platform as the industry needed them to be. Through that, the magical thing known as the virtual machine was born. Java with it's huge, fancy virtual machine could sweep the market because it didn't care what architecture it was on as long as it had a java virtual machine. As the market expanded, interpreters and virtual machine were doing great except for one problem: dependencies. Java apps won't run if the machine they're running on is missing a dependency. Likewise, python apps will crash if the machine is missing a library. The answer to this and all the worlds problems were containers.
Luckily, on the server side, containers make deployment and dependency management easy even for the most difficult languages. With docker, I can pull in an image with a python interpreter that I can wrap everything in. Even with containers though, python seems to do worse than most other languages. Interpreted languages are known for having bloated container sizes (just the base python image is ~1Gb), which is a core reason that new compiled languages like Go can get away with not having an interpreter. Python, being such a high level language, has lots of important libraries that are actually just C code under the hood and when that gets factored into container builds it can lead to slow build and start up times. That's not just a python problem though, the JVM which used to be this really amazing thing now just created bloated containers with extremely slow start up times.
Of course a total rewrite of a code base like this is insanely hard and would be a lot of work but it would also have the unfortunate effect of breaking anything that relies on CPython's C API. CPython can't get rid of the Global Interpreter Lock (GIL) because it would require breaking some of the C API. A Rust rewrite would do that times a thousand. The time and energy it would take to rewrite all the libraries that rely on the C API components of python could end up killing the language entirely. People may just end up deciding that it's not work the effort and more to a different programing language. It seems that with the addition of Tensorflow for Swift and Python Interoperability in Swift, the data science and machine learning community, where I think a majority of the C backed libraries come from, might move over to swift regardless.
Until something major happens, I don't see python going away that easily. My guess is that as time goes on, people will have less and less a need for it. It'll still likely be one of my go to languages for quick prototypes (there's nothing like spinning up a quick flask server for a hackathon). Plus as things stand now, everyone knows or has seen python before so demonstrations in it are safe. But when it comes down to making projects that I plan on keeping for more than a week, I now look at other choices for my language of choice.