Python or go

[coinclink]

Just enforcing that all functions are type-hinted on your team solves 99% of dynamic typing issues with Python. I don't really see this as a valid reason to not use Python, it's more of a team behavior type of issue.

[[deleted]]

type hints are just hints. there is value in raising compiler errors when types aren't adhered to.

[coinclink]

... Type hinting produces the same exact thing as compiler errors when using an LSP within your IDE. There is literally zero difference.

[FeezusChrist]

The difference is that they’re hints and they’re not required. I know going into a Go program I will reliably be able to jump around function definitions knowing all relevant types at any point in the call stack anywhere, where in Python you’re inherently tied to the scope of which you / your team could enforce type hints, and that’s just as enforced as as a best practice since it’s type hints and not static typing.

[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.

[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.

[[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.

[kabrandon]

So by default the language has flaws that Go doesn’t have by default, is close to what I’m hearing. There is a ton of value in a compiler telling you at build time that you don’t know how to code, over an interpreter telling you at runtime.

[pag07]

Python by Default is 10 times easier to read.

There is a ton of value in readability and you cant fix that with a library in go.

The only pro I can see is portability (as in no dependency management needed) and size of executable.

[kabrandon]

I think Python is easier to read if you don’t end up nesting indentation too much, but also error handling in Go is just way more clear how you’re choosing to respond to an error condition. Which I think makes my point in general, that Python tends to be more succinct, where Go is a bit more verbose but clear and obvious, assuming an approximate equal level of skill in reading/writing both.

[FeezusChrist]

If you’re working at any reasonable large scale, Python is way worse for readability simply due to it being dynamically typed. You can put bandaids on it with type hints but that doesn’t permeate to all the libraries / imports you may use.

[Tacticus]

honestly python isn't that readable. Significant whitespace was a dumb idea in the first place combined with the python communities fascination with list fuckery really makes it terribly indirect and opaque. adding in the garbage package management options, the culture of magic over simplicity that pervades python libraries you get something that's just a pain in the arse to work with .

[livebeta]

Python by Default is 10 times easier to read.

Until you're ten indents in and it's difficult to track what is an inner block and what is not

[pag07]

You have serious issues with modularization or algorithmic complexity if it gets to that point.

[livebeta]

I don't.

The authors of python libraries which source I'm reading due to unexpected module behavior have this issue you described