A entire class of bugs, wiped out by a thing called a "compiler". Gigahours of downtime and bug fixing globally prevented by a modest extra step up front. Great stuff.
I had someone say to me they preferred strict type checking in a Python linter over a statically typed language because they "don't like a build step"...
Dudes it's literally just worse compilation with extra steps.
I'm in favor of partitioning the set of reasons it can fail to compile into separate checks with separate tools. Taming the zoo of tooling is extra work, but smaller more focused tools are easier to work with once you understand their relationship to their neighbors.
There's a world of difference between:
> I've been using a different type checker and I like it, you should try it
And
> I'd like to switch our project to a different compiler
Yes, if you are stuck with Python something is certainly better than nothing. But we shouldn't be writing large production apps in it in the first place.
No you don't. You get the illusion of static types without the actual upsides.
For any even medium sized project or anything where you work with other developers a statically typed language is always going to be better. We slapped a bunch of crap on Python to make it tolerable, but nothing more.
I disagree and I've been using Haskell professionally for ten years so I know what I'm talking about when it comes to types. Typed Python isn't perfect but it's totally workable with medium sized projects and gives you access to a great ecosystem.
Everyone knows Haskell is only used for white papers :p
Yeah it's workable, and better than nothing. But it's not better than having an actual static type system.
1. It's optional. Even if you get your team on board you are inevitably going to have to work with libraries that don't use type hints
2. It's inconsistent, which makes sense given that it's tacked onto a language never intended for it.
3. I have seen some truly goofy shit written to make the linter happy in more complex situations.
I honestly think everything that's been done to try to make Python more sane outside outside scripting or small projects (and the same applies to JS and TS) are a net negative. Yes it has made those specific ecosystems better and more useful, but it's removed the incentive to move to better technology/languages actually made to do the job.
I'd say Typescript/JavaScript on the backend are a bad idea across the board. That's not really because of this conversation, just in general.
The comment about Typescript was really about JavaScript. It's a patch on top of JavaScript, which is a shit show and should have been replaced before it ended up forming the backbone of the internet.
Python, typed or otherwise, isn't good for anything past prototyping, piping a bunch of machine learning libraries together, or maybe a small project. The minute the project gets large or starts to move towards actual production software Python should be dropped.
I don't think writing your frontend in Rust instead of TypeScript or your computer vision pipeline in Java would be better at all. We rewrote our frontend in GHCJS (Haskell) at one point and it was a colossal waste of time.
If you read what I wrote you'd see that I said JavaScript/Typescript on the BACKEND is always a mistake. It is an unfortunate reality on the front end, and one that should have been replaced entirely when the web started to move towards webapps.
WASM is obviously an option these days and well, but my understanding is that it's a long way from taking over.
None of those things are to do with typing. Python is slow because it's interpreted, bad at parallelism because of the GIL (which is going away), and bad at deployment because of the messy ecosystem and build tools (although it's pretty good with Nix). Conversely other languages aren't good at those because of static typing.
It is a great choice though for many problems where performance isn't critical (or you can hand the hard work off to a non-Python library like Numpy or Torch). Typing just makes it even better.