| ▲ | felipeccastro 2 months ago |
| I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not? (I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI) |
|
| ▲ | Mawr 2 months ago | parent | next [-] |
| You're hand-waving the insane amount of effort that would be required to type every bit of Python code that gets executed. You get that by default in statically typed languages. Even then, you're reliant on the correctness of a 3rd party tool vs a 1st party compiler. It's never going to be as good of an experience. |
|
| ▲ | misiek08 2 months ago | parent | prev | next [-] |
| You mean compiler vs client reporting issues? Never safer. |
| |
| ▲ | felipeccastro 2 months ago | parent [-] | | Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s. | | |
| ▲ | pansa2 2 months ago | parent | next [-] | | One difference is that Python's type system is unsound. You can write code that passes `mypy --strict` but still contains functions that, for example, claim to return an `int` but actually return a `list` [0]. AFAIK it's not possible to circumvent Go's type system in such a way. [0] https://news.ycombinator.com/item?id=43508152 | | |
| ▲ | kbolino 2 months ago | parent [-] | | The biggest limitation of Go's static type system vs. Python's type hints system that I can think of would be the lack of union types, with nullability a close second (and it's just a specialized application of union types in Python). An interface in Go can be anything under the hood, though you at least know that, whatever its concrete type, it does implement the methods exactly as defined. You can definitely circumvent Go's type system with unsafe operations (with FFI also recognized as inherently unsafe) but that's a clear boundary that you know you're crossing (albeit not quite as clear as e.g. in Rust). |
| |
| ▲ | pdimitar 2 months ago | parent | prev [-] | | It matters the most in practice, actually. Much less production all-hands-on-deck situations. The fact that there still exist people to whom this is not painfully obvious is despairing me. |
|
|
|
| ▲ | pnathan 2 months ago | parent | prev [-] |
| Since Python type checking is functionally optional, it implies that somewhere, somehow, someone has opted out, or has used a type checker that differs subtly but unpleasantly from the one you're using. Python's type checker systems are fundamentally a _linter_ more than something like Java or C...or Rust. It's not about feeling. It's about the theorems you can make about the codebase. With Python the answer actually is ¯\_(ツ)_/¯. |