[est]

I think "types" is the solution of two completely different problems:

1. how to specify memory layout for faster execution

2. how to give hint when I press . in IDEs

if you use typing outside these two scopes you'd probably find many troubles.

[acchow]

> if you use typing outside these two scopes you'd probably find many troubles.

- encoding invariants and define valid evolutions of the codebase

- memory safety without a garbage collector (see Rust’s Affine type system)

[hnlmorg]

3. Compile time safety.

That’s what I use types mostly for. I don’t care about compiler hints, well structured code with sane naming conventions solves that problem without the need for types. But I do want my program to fail to compile (or in JIT-land, fail unit tests / CICD) when I do something stupid with a variable.

The former is about typing speed and I already type faster than I think. The latter is about guardrails protecting me from my own human error. And that is a far more realistic problem than my IDE performance.

[grues-dinner]

Not only compile time, but run/debug time. Just being able to say "I have an object here, so I must have some consistent state meaning XYZ" is very helpful.

Of course, it's on you to make that happen - if you have a Between6And10 type and you implement as struct with an int that someone comes and writes 15 into it, it's bad news for your assumptions.

If you can make it compile time safe, then great, but even when you can't, if you know the invariants are holding, it's still something powerful you can reason about.

[grues-dinner]

Types imbue pure data with meaning. That's pretty much it, and the other uses of types flow from that.

Whether you use that meaning to produce IDE hints (say, via Python type annotations, though I am aware Python typing isn't only that), or you feed it to a compiler that promises that it will ruthlessly statically enforce the invariants you set via the types, or anything else, is up to you, your goal and the language you use.

[mrkeen]

They also imbue code with meaning, not just data.

For isn't, the return type STM () doesn't give you anything back, but it declares that the method is suitable for transactions (i.e. will change state, but can be rolled back automatically)