It's a no holy war post! Any choice of languages cannot be 100% objective, and I'm just sharing my experience here.
When I was a kid, I used to spend days tinkering with woodworking tools. I was lucky enough to have a wide set of tools at my disposal. However, there was no one around to give me a hint about what tool to use when. So, I quickly came up with a heuristic: if my fingers and a tool survived an exercise, I've used the right tool; if either the fingers or the tool got damaged, I'd try other tools for the same task until I find the right one. And it worked quite well for me! Since then, I'm an apologist of the idea that every tool is good only for a certain set of tasks.
A programming language is yet another kind of tool. When I became a software developer, I adapted my heuristic to the new reality: if, while solving a task using a certain language, I suffer too much (fingers damage) or I need to hack things more often than not (tool damage), it's a wrong choice of a language.
Since the language is just a tool, my programming toolbox is defined by the tasks I work on the most often. Since 2010, I've worked in many domains, starting from web UI development and ending with writing code for infrastructure components. I find pleasure in being a generalist (jack of all trades), but there is always a pitfall of spreading yourself too thin (master of none). So, for the past few years, I've been trying to limit my sphere of expertise with the server-side, distributed systems, and infrastructure. Hence, the following choice of languages.
Level up your server-side game — join 6,000 engineers getting insightful learning materials straight to their inbox.
The most appealing thing for me in Python is the tremendous pace of development this language can provide. It's easy to write code in Python. There is often one clear way to accomplish a task, and you don't have to think much about how to convince the language to do what you need. Instead, you can focus on the business logic. I use Python for quick prototyping, for the performance-tolerant server-side code, for ad hoc scripting, and of course, for data analysis. I started my Python journey in 2014 and, without any prior experience with the language, managed to single-handedly develop a service that quickly got thousands of active users a day and survived the load without a lot of rewriting.
Unlike Python, you may need to fight the compiler to get things done with Rust. But if you manage to compile your code, the result is guaranteed to be safe (well, unless you abuse
unsafe blocks). And most of the time, the result is also quite performant. I personally find this dancing with compiler quite rewarding, but I have to admit that the development pace degrades a lot. That's why I use Rust only when it's really necessary - for performance-critical tools or systems programming. I don't consider myself a knowledgeable Rust developer just yet. The language is in my toolbox only since 2020. But I hope with pq I'll be spending more time writing Rust this year.
I don't write code in C. But I find the ability to read C code fluently a must-have in my domain. The Linux Kernel is written in C, and it makes it a native language for the whole family of operating systems. I always strive to understand how things work one- or two layers of abstraction below my code. Often it means I need to dig down to libc calls and try to reproduce snippets from man pages using bare C. Sometimes reading the libc code itself also helps. When I really have to wear a hat of a systems programmer, I turn to Rust instead. My acquaintance with C lasts from 2006-2007.
Well, that's probably it. Hope I didn't bore you to death with this rant :)
Level up your server-side game — join 6,000 engineers getting insightful learning materials straight to their inbox: