Comment by cbb330 | Hacker News Reader

Comment by cbb330 | Hacker News Reader

Parent Full thread

I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo.

Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter notebooks. But at scale there are no success stories. You are zoomed in on the present success of "engineering miracles" and ignoring the big picture that the application would have moved faster if they had the foresight to choose a typed language.

Hence, why i'm saying be warned on following the path of mypy+black+pyright+ruff+etc., since you will be doomed to patching on top of a fundamental flaw of the language.

I highly recommend to avoid Python for production apps especially if it is your free will (and not a matter of refactoring or rewriting existing mistakes).

>But at scale there are no success stories.

Do you believe this yourself?

yup! along the dimensions of feature velocity and developer experience with regard to cost.

of course python/ruby/javascript have succeed in bringing value to the world in general -- but in this thread we're focusing on production reliability, debugging, refactoring.

as we see, dropbox is proud to admit that they hired Mypy core developers and fund the project, but guess how much they spent on the mistake of using python?

twitter, famously an advocate for Ruby, spent an ungodly amount of engineering to work around ruby, hit a wall, and switched to JVM.

Just the fact that mypy and typescript exist and have exploded in adoption is proof that eng. teams very quickly hit a sand pit when using dynamic typed languages. Mypy being funded by dropbox, Typescript funded by microsoft, shows the level of investment needed to support these dynamic languages.

So the thousands of developers using Python either doesn't know their own best or are just in perpetual pain in their use of python? There isn't the slight possibility that your view on what is a useable programming language in production is subjective and not objective?

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain.

And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on.

The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynamic typing hits a scale limit of feature velocity / production support / cost much faster than the general folk are aware of.

What would happen to our 10x advantage if every tech would suddenly believe you and leave scripting languages in the toy box?

by no means is go/java/rust/c++ a silver bullet. it is a way to raise the bar for debugging, reliability, support. it is more effective than bundling python with 5 other type bandaids. in the medium/long term, lets guess at 2 KLoC or >3 person team, these typed langs will result in faster feature development and lower issues in production.

What compells seasoned developers to keep using python if these flaws are so obvious, though?

its comfortable, easy, appealing in the short term. just like why people overeat their junk food.

there's this common idea in management that new grads, SREs, "less experienced devs", can jump in and contribute. it's a falacy because the code becomes unmaintainable without a large investment (more unittests, refactoring the "buggy" code blocks with mypy type annotations, some SME who continues fixing prod bugs). a Python developer will shove their head in the sand with repl'ing, testing after deploy, and settle with this dev/ex while being completely unaware of the benefits of compiler errors and warnings.

Python has the same level of complexity as another language but you'll only see all of that dirty baggage in production as runtime exceptions.

Reply on news.ycombinator.com