But look at where it got us. At every company where I've worked with data scientists, every piece of "data science" code is written twice -- once in Python, and again in another language. We had to hire at least one software engineer for every data scientist. There is an entire industry that targets "productionalizing" things written in Python by data scientists, because Python code is not production-ready code.
Python for education? Absolutely. Python for whiteboard interviews? Great. Python as a DSL for data science? Obviously. Python as a scripting language? Sure.
Python as a production-ready language for a growing company? I have spoken to people at lots of companies that started with Python, and then had to dedicate months or years for a full rewrite. And if they have people writing Python code, they have hired more people to rewrite that code immediately so it's not in Python anymore. I say "bye" to every interviewer who pitches me on a job writing Python: every time I have looked into an opportunity like that, it was an attempt to throw fresh meat at rewriting a creaky, unmaintainable Django monstrosity. This isn't me being an armchair philosopher, this is the industry around me.
Here are some examples https://learn.onemonth.com/10-famous-websites-built-using-py... (some, like Google, are a bit dubious)
I can agree that large projects in dynamically typed languages can be unwieldy without type hinting but there are tools to make it manageable (Ruby, JavaScript, and PHP are no different in regards to typing)
> We rip out and replace older Python code
Which seems like an entirely reasonable way to use Python (no quotation marks needed), and exactly what I'm advocating - Python is a language where you can ship something today and reimplement it next year, also in Python, for the same engineering effort that you'd spend doing it once in a more highly structured language. Alternatively, you can reimplement it in another language. You can safely rip out and replace the original Python, because it's a language that optimizes for humans both reading and writing it.
And just about every place I've worked, business requirements are constantly changing, and the scale and structure of the company (and associated Conway's Law implications) are changing, and so code you write today is going to be tech debt in a year anyway. A language that encourages you to write outrippable code and makes it easy to replace it is your ally under these conditions.
(Put another way: Python is a language that is readable enough to avoid the https://www.joelonsoftware.com/2000/04/06/things-you-should-... trap, which is fundamentally about code that is so complex that a human can't figure out all of what's going on and the only safe way is to treat the existing code as a relic.)
Again, I'm not saying this is the language for everyone to use for all cases. There are cases where you want to make the code a little harder for humans to read and write so that the computer can help you with things. If that is indeed your use case, go write Java! But I think there's plenty of stuff you can call "production-ready" that doesn't fit this particular mold.
[1] https://www.artima.com/weblogs/viewpost.jsp?thread=98196
Not true: it was moved from builtins to `functools` module, but it's still there.
> Only reduce will be removed from the 3.0 standard library. You can import it from functools.What he meant to say is that it's removed from the list of builtins.
I agree there's work to be done in closing that gap so you don't need an extra software engineer for productionalizing mostly-working Python (and I'm excited about tools for managing large-scale Python - e.g., several of my coworkers are trying out MyPy, which I haven't personally felt too much of a need for but seems like it could help), but the gap exists precisely because you can write something working in Python quickly, and it's not so much of an investment that you'd feel bad throwing it away if it doesn't work.
The company that started with Python and spent years on a full rewrite made enough money with Python to survive those years. If they had started in a more "production-ready" language they might not have shipped at all, and if they did they might not have shipped the right thing.
And at least for me personally, as an infra person, the question I'm evaluated on at the end of the day (or year) is "Did the infrastructure work," not "Did you write production-quality software to support the infrastructure." Some of the most critical software I've written (across multiple companies) has been 50 lines of Python shared via a Slack snippet or a shared homedir and only retreated into version control months later. There are a lot of problems that genuinely require only 50 lines of complexity, and the ceremony of a language like Java makes it much harder to understand what's going on. For those problems that do require umnanageable Django monoliths, by all means, write it in something else.
ML is famous for it and python is the most used language there.
This is sort of why I like Python: it prioritizes getting something working today and trades off being able to build a complex system over several years. Java is a great language if you're going to build a large-scale application and want a bunch of developers across time and space to productively contribute to it. But business requirements change, and if you can get what you want done by using a series of applications that live for a few weeks or months, why wouldn't you do that?
Another commenter mentioned scientific computing, which is a good example. When you're evaluating hypotheses, it's important to be able to write new code with high throughput. That means you need enough power of abstraction to be able to have libraries like NumPy etc., but you don't want so much structure that it's hard to write 10 lines of code and validate or falsify your gut feeling and then move on. Python was built around a REPL; Java only grew JShell fairly recently, and Jupyter was built for Python, not Java.
And even when you're trying to reproduce old work, it's a lot more scientifically valuable to have someone be able to look at the paper (the spec) and write a new implementation than to say "Start with this 100 kloc Java codebase which we wrote for Java 1.2 but still works today." There are of course useful applications for that capability and it's great that Java supports it, but this isn't one of those applications.
I don't do scientific Python myself, but I support users who do and I do a lot of infrastructure work. For that, it's still much more valuable to be able to write new code and get rid of it than to work within an old and well-built system. If I want to answer questions of, say, what our storage use patterns look like so the business can figure out what to invest in, it's a lot more valuable to be able to take that problem statement and produce an answer quickly than to build a long-lasting application that can keep producing answers to variants of that question, because the next question isn't likely to look too similar in terms of implementation.
Or maybe put it this way - if you're the IRS, and you're writing code to process and verify people's tax returns, Java sounds great. You're going to want to keep the tax code from N years ago still working, and you're going to want this application to live many years. But for me, I have a little program to do the math for me to fill out my taxes, and that program is in Python, because I have no need to keep maintaining the script when the tax code changes (or when I move states), and I'm the only author. I make a copy of the Python file each year and I drop anything irrelevant. The ability for me to read the entire script top to bottom and be convinced "OK, this solves this one task accurately" is far more valuable than the program being able to solve hundreds of tasks it needed to solve in the past.