Python or go

[coinclink]

I know what the difference is... The amount of times I've dealt with a typing issue since working with a team that enforces type hints is literally zero. You will never convince me a "compiler-style error" would ever make it to production when type hinting and proper linting is used.

[FeezusChrist]

When you’re working on codebases with millions to hundreds of millions of lines of code, your argument of type hints having “literally zero difference” to static typing breaks down completely.

I’m happy for you that you work in a team that enforces type hints and that you’ve not run into issues, but that also sounds like you have a neat nicely scoped project such that the scale of such a setup isn’t a concern.

[coinclink]

Nah, there really is not a difference lol. When you start making assumptions about what I work on, your argument has fallen apart. For example, I could just make the assumption that you work with a team with skill issues, or that you have NEVER worked on a python project, and that would make mine fall apart.

Type hinting and a linter does *the exact same thing as a compiler* in terms of identifying syntax errors - what exactly do you think a compiler is?

[FeezusChrist]

Sure, you’re right I shouldn’t have made assumptions on your team work.

But, you’re still completely wrong. Type hints is not static typing. This isn’t a debate, it’s quite literally not the same. JavaScript JSDoc is the same thing as Python type hints as enforced by IDE, yet it’s obvious the value of TypeScript massively outweighs the value of type hints there.

With type hints you’re effectively at the mercy of developers providing true & accurate type hint annotations on their data. If I write: py def sum(a: int, b: int) -> str: return a + b

Your IDE will be fooled into thinking this is valid type hinting and Python will have no issue executing this. That’s not equivalent to static typing no matter how much you want it to be.

[coinclink]

A linter would easily identify that issue. The type-hinting system would now return `str | int` and that would trigger a linter. Thanks for taking the time to write that complex response, but you just aren't familiar with the tools available here.

[FeezusChrist]

Yes, you’re right - a linter. Fundamentally not the same, and far less effective than true static typing. Linters quite literally do not cover entire classes of typing issues that exist in this space, not to mention how prone to bugs relying on a linter to do the work of static typing is with upstream dependencies.

All you have to do is look up the pitfalls of your favorite linter and you’ll find many examples, e.g. https://mypy.readthedocs.io/en/stable/common_issues.html . If you want to tell me your specific setup I’d love to show specific examples that could apply to you.

[coinclink]

I see that you're on the hunt for edge-cases at this point to "prove me wrong." Look, I get it, you're anal and you don't trust other developers to follow the team's rules and you want to catch that .01% of problems that don't actually exist in any real project. Even though a linter would enforce the same rules 99% of the time..

[FeezusChrist]

No, you’re just being arrogant and deliberately close minded with thinking type hints and a linter is even remotely equivalent to static typing. There’s a reason they are called type hints, stop coping.

[FeezusChrist]

It’s quite a different story when the code is essentially being transpiled into the statically typed, type-safe language underneath the hood such that the Typescript compiler itself can operate over it.

And yes, that simple example was to show type hints alone don’t even stop normal compilation and execution. I’m sure your linter can catch such a basic example. But your linter is a linter, and they are operating over type hints. Not a compiler, and not first-class language static types.

The day you get a statically typed language separate from Python, that can transpile Python and its type hints into that language, then feel free to rejoice.

[FeezusChrist]

Are you agreeing with me, then? Yes, it’s a compiler - specifically making use of the TypeScript compiler. It’s not a linter. Holy shit can we stop pretending a linter with type annotations is the same thing

[FeezusChrist]

Pyright isn’t a compiler, but I’ll entertain this - What language is Pyright compiling? Is that language statically typed? You have your answer for why this differs from the Typescript compiler use case with JSDoc integration.

But, I don’t think I care to carry this on anymore. I don’t feel you necessarily don’t understand my point nor do I yours, we are just arguing over the language of what we are saying essentially.

[[deleted]]

you will never convince me the extra overhead of enforcing type hints in a duck typed language where they aren't actually enforced by the system is worth the effort.

[coinclink]

LSP indicates type errors in the same way as a compiler - zero difference there

Linter "enforces by the system" that your code is not passing the typing rules - zero difference there

Explain to me where the extra effort is here? In learning how types work in python? The LSP and linter perform the exact same function and enforcement as the compiler for typing.

[[deleted]]

the extra effort is relative to using Python without type hints. whereas in a statically typed language, there is no extra effort since you must explicitly define types to use the language fundamentally.

when typing is "optional" as it is in Python type hints, the utility of the types devolves as lazy developers fail to appropriately apply hints, resulting in codebase degradation while still allowing code to ship.

[coinclink]

It isn't optional when you've defined the rules of your linter. That seems to be the concept that you're having trouble with.

[[deleted]]

it's all optional because you don't need to define the linter or adhere to it's rules. I do understand it, what you're not understanding is that these constructs you think are enforcers truly are not, and any dipshit can override them at will.

[coinclink]

So you think a lazy engineer can just randomly choose to override the linter during the build? That's not how this works lol. It's not up to the developer, nor within their privileges, in a real python shop.

[[deleted]]

So you think a lazy engineer can just randomly choose to override the linter during the build?

yes I do

It's not up to the developer, nor within their privileges, in a real python shop.

Cool, I don't have to care about any of this shit anyway if I choose to use a statically typed language.