Production ready is a red herring. Facebook was built on PHP and found a way to make it work. There a plenty of massive websites running on Python.

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)

On that list, I only have first-hand experience with Uber. The Uber entry on that list links to a blog post from Uber engineering. This four-year-old blog post says:

  > We rip out and replace older Python code

How many other companies on that list also "use" Python the same way that Uber "uses" Python?

If you follow the link next to that text, it says that they're ripping out sync Python using Flask from their monolith and replacing it with async Python using Tornado in a microservice, though some teams are also exploring Go.

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.

I wrote that I have first-hand experience at Uber because I was ripping out that Python. There is no more Python, and certainly no more has been added in the four years since that blog post was written. Python is only for scripting data pipelines and automation. Almost everything else is Java/Go.

Python isn't only unwieldly because of dyanamic typing, but also because it eschews functional idioms. JavaScript is much better in this regard, and it makes the code much more maintainable.

Do you have any examples in mind?

Sure, `reduce()` was removed from the standard library between Python 2 and Python 3. Here is Guido arguing that `lambda` and several other functions should be removed as well.[1]

[1] https://www.artima.com/weblogs/viewpost.jsp?thread=98196

> `reduce()` was removed from the standard library

Not true: it was moved from builtins to `functools` module, but it's still there.

Please tell Guido that he got it wrong!

  > Only reduce will be removed from the 3.0 standard library. You can import it from functools.

He did, in fact, misspeak. functools is part of the standard library, and was part of the standard library in 3.0, and contained reduce: https://github.com/python/cpython/blob/3.0/Lib/functools.py#...

What he meant to say is that it's removed from the list of builtins.

To the point about data scientists - there isn't really a way you could solely hire the software engineers, right? So there is value in Python allowing the data scientists to iterate much quicker than they could if they were writing in a "production-ready" language.

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.

Given that 90% of companies fail, maybe that's a good tradeoff. Build the thing that might work in Python, see if it gains any traction (the famous product-market fit), and then rewrite it if it worked. If Python saves you more than 10% of the effort on the first write, then on average it's worthwhile.

What were the other languages you were rewriting the Python in for production?

Thankfully, this rewriting has never been my job. Companies where I've seen it were typically targeting Spark as the execution environment, so the production languages were Java and Scala, at a ratio of about 2:1. PySpark in production was either disallowed up front or quickly disallowed retroactively after experiencing the magic and delight of data scientists shipping production PySpark.