No, it's one of the fastest ways in software development you can ship software features to the customer.
Scripting language, dynamic typing, microservices and a message queue is shockingly effective.
There is no way to compete with that if you are using traditional development techniques.
It's why we watch videos online on Youtube and not Google videos. The Google developers got beaten up by the much smaller group of Youtube Python developers.
To be honest, I find it shocking that the average user on hacker news doesn't know that software development using dynamic typing is considerably faster than software development using static typing.
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?
Have you ever of this little company called Youtube?
Youtube did the dynamic typing thing in Python with 20 developers and Google did the static typing thing with several hundred developers in C++ for their Google Videos.
Nice anecdote, but was it because of the language or because a small motivated team gets much more done than a big enterprise that is bogged down in meetings?
You seem to be quite close-minded, every piece of evidence is not good enough. Are you only going be satisfied by a 20-year long peer-reviewed independent study?
How about this: Python is only ~1.5 times more popular than Java, and Ruby is way below Java, and yet if you look top successful YC startups, Python has 17% of valuation, Ruby has 52% and Java is merely 1%. You can, of course, choose to interpret it in a multitude of ways, but at least one of them is that if you pick Java for your startup, you are unlikely to be successful (or, alternatively, people who are unlikely to build a successful startup are more likely to choose Java).
