Ah, so your reasons to pick a different language are based not on type safety, but on performance.

Indeed there may be a plethora of valid reasons to pick another language over python for some project. But that wasn't the question.

Type safety of Go is leaps and bounds better than python's will ever be, with mypy or not.

That's just factually untrue.

Mypy supports generics, protocols, (via extensions) dependent types, and user-defined covariance rules. Its leaps and bounds more powerful than go's type system.

Pytype adds type inference to that list. You end up with a type system that's closer in power to Scala's or Haskell's than Java or Go's.

Mypy's various bugs are just indicative of how much of a band-aid it is.

If you truly believe that a dynamic language like python can have type safety, then imagine what a language like Go can achieve.

Python already has deviated too much from where it started and mypy offers too little to justify the verbosity.

So I guess we'll see what the future holds for them.

>If you truly believe that a dynamic language like python can have type safety, then imagine what a language like Go can achieve.

Literally exactly the same thing, but no more.

Mypy and Go's compiler have the exact same information available at compile time. Python stops being a dynamically typed language when you add Mypy. It becomes statically typed. Calling it "dynamic" is like calling C++ "dynamic" because C++ doesn't have access to run-time type information (usually).

Actually that's not true, due to the increased expressiveness of Mypy's type system, it has more information available. Mypy has more information. It can do stronger analysis. Go has less information, it can't do as much. Go can make language (syntax) changes to improve this. Python has been very smart, and the type system is implemented as normal objects using the normal syntax. Adding new types, even "special" ones (like Union or Interface) doesn't require modifying the language itself, but can be done only with modifications to a fairly nimble standard library module.

This allows python's type system to evolve much more quickly than Go's has shown itself capable of.

>Python already has deviated too much from where it started and mypy offers too little to justify the verbosity.

But python's type system offers more than Go's, and isn't particularly more verbose, so what are you saying here about Go's type system?

> Go can make language (syntax) changes to improve this. Python has been very smart, and the type system is implemented as normal objects using the normal syntax

I will leave this tidbit here:

i, found = 0, False # type: int, bool

In any case, I find these new "typing" features very awkward, overly verbose and not the reason that I chose python in the first place. If I am to write all this non-pythonic stuff to be 10x+ slower, less memory efficient, awful at concurrency and still not having solved the packaging/deployment situation... I will just use Go. Or any other language in that league, that offers so many more nowadays.

> i, found = 0, False # type: int, bool

That's actually

    i, found: Tuple[int, bool] = 0, False

in python3. Which as I said, uses normal objects and normal syntax.

As for the rest of your comment, I think that's been well discussed. There are a variety of non-typing reasons to use go over python. But if you are about type safety you're probably better off with modern python than modern go.

> normal syntax.

Right. Ok we have a problem with definitions. No this is obviously not normal syntax.

Unless we take it to mean "whatever new syntax python introduces is normal syntax, since it supports it!", which is tautological and not very useful.

I'm gonna say something, strictly so you can understand where I'm coming from, not to offend you.

You sound very young. And by "young", I mean so young to not remember that Python was always about "duck typing" and not about strict types. I still have books on my bookshelf that tried to dissuade you from using "issinstance(foo, sometype)". So no, it's not python or normal syntax.

Yes, Python now is safer than older Python. But I had 99 problems with Python and that wasn't one of them :(

You, speaking as if Python is progressing so fast while Go is standing still, feels disingenuous. Go fixed their dep/packaging woes in a few years, Python is not even close. Go is adding generics. Go becomes faster in almost every release.

Changing Python into something that doesn't resemble python, its values, or the reasons that people chose it in the first place doesn't make sense, nor does it make it "Python".

I don't want Python to become Haskell, Rust or Go. No one ever chose python for its typing system! Rather its lack of it.

Anyway, there's no accounting for taste and to each their own.

Cheers

> Mypy's various bugs are just indicative of how much of a band-aid it is.

I think you're confusing an idea with an implementation. Bugs can be fixed. If mypy is useful, it will remain useful and slightly more stable.

Go has to be better than that. Java beats Python by a factor of 10, and C beats Java by a factor of 10. C is beating Python by a factor of 100. I would expect Go to be a bit faster than Java.