Nowadays, the speed of development for statically typed languages is much faster, thanks to improvements in tooling. Going further, if you choose a modern language that supports type inference, static typing becomes a pure win, and in my opinion, there's no longer any good reason to use something like Python on the back end. If I had to pick a language for the situation you're describing, I might pick something like Kotlin.
My background for context: in 2000-2009 or so I wrote a lot of C++ and often wrote Python bindings using Boost::Python because of how much quicker and more convenient Python was for scripting and exploratory work. I also wrote a lot of Java in that era, and Java was indeed incredibly verbose and ugly. Like C++, it imposed heavy costs for the benefits it gave you. After 2010 I worked mostly in Scala, and for a year now I've been working primarily in Python. The simplicity of working in Python still feels liberating, and doing Pandas work in Jupyter is great fun, but in most ways it feels like a relic to me now, because I can write code that looks almost as simple and reads just as easily in Scala as Python. (Sadly, I wouldn't recommend picking Scala for a tech stack in a business, because it's hard to find Scala developers who want to write stupid simple code.)
> Nowadays, the speed of development for statically typed languages is much faster, thanks to improvements in tooling
What you static camp guys don't seem to understand is that tooling is not that important, it's just a minor multiplicator that caps out pretty fast. You can't turn nurse into a surgeon by giving her a sharper scalpel.
Most engineers that had Java background I interacted with had a tendency to over-engineer. It's not because they had bad tools, it's because Java has a culture of over-engineering, which they soaked in and embraced. Tools & language are getting better - that's great. But that does not automatically fix the culture, which might take another decade or two.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
At this point, Java is like BASIC. You can fix the language all you want, but you also need to fix the culture. It's not going to happen while most people won't even admit there is a problem.
We're talking about backend development, and in that domain Python has its own set of pretty awful drawbacks.
Starting with needing a level of testing that would make even the most paranoid static-language devs spit their coffee out. If you have any untested code and need to make changes that affect it, you are incredibly screwed. I can make sure my own code has the necessary level of testing, but when I'm at the mercy of other people's test coverage, I'd rather have the help of a compiler.
The performance of tools and tests is noticeable every day. Unit tests and linting are palpable interruptions. One thing I notice constantly is the delay when asking my IDE to add imports. With Scala, I can get it done almost as fast as my eyes and brain can work. With Python, it takes a few seconds before it can offer me the right import.
Speaking of performance, we were excited to discover ruff on HN a few days ago, which advertises a >100x speedup over flake8 -- it's written in Rust, flake8 is written in Python.
Writing C++ and Scala, the attention paid to performance in 95%+ of the code we wrote amounted to using efficient algorithms and not making stupid mistakes. Computers are amazing these days, and if you write straightforward code with good data structures and algorithms, code on the JVM runs incredibly fast, almost always much faster than you need it to. With Python, sometimes you use the right representation and the right algorithm and the result is still disappointing, because in the absence of a JIT, good Pythonic code is a huge multiple slower than it needs to be.
In many cases where performance has been disappointing, we've decided to live with the slowness, because making it faster would mean departing from the straightforward Pythonic style that gives us easy-to-read, easy-to-test code.
> At this point, Java is like BASIC. You can fix the language all you want, but you also need to fix the culture. It's not going to happen while most people won't even admit there is a problem.
This is one thing I agree with. Java and Scala development both have culture problems. The Java world has a disproportionate number of programmers who believe that the imperative, mutable-everything, deep inheritance hierarchies OO style of the 1990s and early 2000s is an eternal truth of software development, and programmers are either virtuous and enlightened OOP warrior-monks, or benighted stray sheep. Apparently most people who don't believe that have jumped ship to other languages, making the problem worse than ever. Scala's cultural problems have been adequately discussed here, so I won't repeat them. In my experience, the best Java code, and the best Scala code, is written by people who are deeply suspicious of the culture associated with both languages.
> If you have any untested code and need to make changes that affect it, you are incredibly screwed
But you aren't. If your software isn't landing airplanes, you shouldn't treat all bugs as critical. Build safety nets, not guard rails.
Python might have 10% more non-critical bugs, but also allows you to ship 5x faster. That's a great tradeoff for vast majority of projects.
> Unit tests and linting are palpable interruptions.
I do believe some teams have this problem, but mine never had. To me it's a signal of many tangential issues (bloated codebases, obsession with unit testing). I don't believe it's a language-specific problem. Also, you should just lint-on-save anyway, slow linting in CI is a minor nuisance.
> Speaking of performance, we were excited to discover ruff on HN a few days ago, which advertises a >100x speedup over flake8 -- it's written in Rust, flake8 is written in Python.
In order to create a better flake8, you have to create flake8 first. The reason flake8 exists in the first place might be that it was easier to create in Python. First succeed, then optimize, not vise versa. Also flake8 is a CPU-intensive command line tool, not your typical environment for Python.
> Apparently most people who don't believe that have jumped ship to other languages, making the problem worse than ever
> In my experience, the best Java code, and the best Scala code, is written by people who are deeply suspicious of the culture associated with both languages.
I believe that. I think culture will simply push good engineers out of those communities. If you have to fight both language and community, why would you stick around?
Nowadays, the speed of development for statically typed languages is much faster, thanks to improvements in tooling. Going further, if you choose a modern language that supports type inference, static typing becomes a pure win, and in my opinion, there's no longer any good reason to use something like Python on the back end. If I had to pick a language for the situation you're describing, I might pick something like Kotlin.
My background for context: in 2000-2009 or so I wrote a lot of C++ and often wrote Python bindings using Boost::Python because of how much quicker and more convenient Python was for scripting and exploratory work. I also wrote a lot of Java in that era, and Java was indeed incredibly verbose and ugly. Like C++, it imposed heavy costs for the benefits it gave you. After 2010 I worked mostly in Scala, and for a year now I've been working primarily in Python. The simplicity of working in Python still feels liberating, and doing Pandas work in Jupyter is great fun, but in most ways it feels like a relic to me now, because I can write code that looks almost as simple and reads just as easily in Scala as Python. (Sadly, I wouldn't recommend picking Scala for a tech stack in a business, because it's hard to find Scala developers who want to write stupid simple code.)