Choosing the right programming language
July 25, 2017
One of the questions I am asked most often when it comes to programming languages is something that boils down to “should I use X over Y to achieve programming nirvana”. If you believe language evangelists, you would think so. You can make lots of good points to use X over Y or X in general. And maybe even the downsides are mentioned at some point to make it look like an not so opinionated comparison. The question remains - when should you pick which language for your next project?
I am trying to look at this form the point of view of someone getting into programming or already being into it and planning to work on a new side project. While some of the arguments hold up well in a business or team environment, some of them get less relevant or eventually completely change if we have an already existing codebase.
I do not believe it is a secret that I really enjoy Golang and Swift. Maybe even that I had a hard time with Python and its community the last few years. In the business world I feel ambivalent about Java, for side projects I still see the arguments made in a business setting but I would not touch it if not absolutely necessary.
Based on this it sounds like I would most likely start new projects in Golang or Swift. Especially considering Swift is the new, overly hyped newcomer in web development and it could be fun to actually ship a web service or app written in Swift - also, I will most likely do this at some point. And still, I created a virtual environment using Python 3 and installed Django when starting a new project I actually want to get live soon-ish.
Why should I not have used Python and Django?
- it is slower than the alternatives
- deployment is a lot harder
- it lacks a few things I appreciate in a language like static typing (no, type annotations are not a sufficient replacement, even if they are a decent band aid)
- for anything outside of the CRUD world Django simply gets in your way
Only to name a few points. But still, why did I start a new project using this old, slow and definitely lacking technology?
- it works. There are no surprises and there are battle tested libraries for everything you need - read: DO NOT ROLL YOUR OWN AUTH
- some of the problems only need to be solved once, so over the lifetime of the project they can be neglected
- nearly no project will get to the stage where one or two app servers cannot handle the load. If they do: you got more important problems to solve than adding a third server. But performance and scalability are far less relevant than benchmarks make you believe.
The “do not roll your own auth” part is my favourite one to explain my point about battle tested third party libraries. To roll your own auth you also need to solve proper password hashing. Also session creation and termination. And resetting passwords. And and and,… there is a lot related to this. We are talking about one of the areas in a web app that can make your project the headlines of some random tech blogs telling everyone that you lost user data. You literally cannot mess that part up without jeopardising your whole apps security.
I am not saying you should never do this. Once you understood the concepts implementing basic functionality is pretty straight forward - while writing this I notice I should increase my blog draft directory by one more explaining how to do this - but it still consumes quite a bit of time, work and you have to rely on a few third party libraries, like one to hash passwords, which are hopefully properly vetted and tested.
Golang libraries for authentication, for example, do not even come close to Djangos or Flasks packages, even after roughly 6 years or so and quite a few attempts by really smart devs. They do some of the things you need. Sometimes even in a way that you could theoretically integrate them with enough work. But they never get you the same comfort, luxury and safety as the ones in the Python world. The same goes for templating. Admin interfaces. ORMs. The list goes on.
There are certainly situations that strongly suggest choosing one language over another. Sometimes there are specialised languages, like R, sometimes there are simply natural fits like writing iOS and macOS applications. But strictly looking at general purpose language for web application development it simply comes down to one question: Do you want to get a product done or do you want to play around with a language and maybe create something as a side effect.
If you are set out to create a product use whatever you are comfortable with or what seems the easiest for you to learn when just starting to get into programming. It is 2017. Servers are cheap. Scaling to a certain point is a well understood and solved problem. And getting started with something that is not quite the right fit is better than thinking about languages for dozens of weeks and not getting any real work done.