Hacker News Reader

Comment by pnathan | Hacker News Reader

Agreed. I had to work in a larger Python codebase after spending a few years with Go and Rust and the drop in logical confidence around the language was remarkable.

I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.

View on HN

Same, though my trauma was Ruby. Those Rubyists who were apparently born with the language spec in their heads can do amazing things, but I am a mere mortal who needs to be told I wrote bad code right when I wrote it, not told at 2am on a production server.

do you not test your code?

In a large enough code base, there is no "your code". There is the code you wrote today, there is the code you wrote two years ago, there's all the code people are writing around you.

I change a function's arguments, I'm _pretty_ sure I caught every place it's called (spoiler alert: I didn't, because someone calls functions dynamically based on their names with call_user_func_array, maybe), and I ran the test suite - everything works, and I've fixed what doesn't.

Except some of that old code written 8 years ago didn't have good tests, or didn't have any tests at all, or didn't cover the specific code path.

And now it's 2am on the production server.

Now, you could tell me - Pavel, you're an engineer, you should be sufficiently dedicated to your craft to verify that the tests are testing those paths, you should find all those instances where that function is called (a few dozen times across the codebase), and check that those tests exist and are good. And you're not wrong! I should be doing cleanup in the codebase as I go, washing those dishes while I wait for pasta to boil or whatever...

... but now I've given myself two more actual engineer-weeks of work for a change that just needed to add a flag to a function to make sure only premium users get emails when something happens. My manager will be thrilled to hear it. Do you think I'll get a raise?

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)

You mean compiler vs client reporting issues? Never safer.

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.

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

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

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.

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.

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 ¯\_(ツ)_/¯.

Firm like:

  https://coalton-lang.github.io/20211010-introducing-coalton/

?

I need to spend some quality time with Coalton. I don't think it's _quite_ what I want, but its in the same key.

Reply on news.ycombinator.com