The goals of a particular programming project determine what's optimal for it in terms of the programming language of choice and particular idioms that will be used. I wouldn't want to play four-dimensional chess against Rust's borrow checker for a one-off analysis that can be done in one line of R (or even without any programming at all, in Calc). But I also wouldn't want an unchecked dynamically typed virtual machine with a stop-the-world garbage collector piloting my spaceship. For common tasks, use a universal programming language and the most common idioms it can offer; it's probably the best solution, and reality says it should work (since it works for everyone else). For quirky projects with their own special requirements, the best tool may be different. Make sure to define a code style and follow it. It's annoying how in certain areas of programming, "the one obvious way to do it" is a function of time. Think of how many web frameworks, nay, whole paradigms about how the Web should be programmed we have witnessed coming and going: we went from simple but slow to launch CGIs to application servers for faster response and dedicated application virtual machines for easier deployment (and switched approximately 6 languages in the process). All of these approaches were probably locally optimal for most projects they powered at the time. Should I rewrite my numpy pipeline to tensorflow so that it would work faster on a GPU? Or is it torch? Should I wait for better GPU support in jax? Will the pile of dependencies come crashing anyway when I revisit the code a year later?