There is no good definition of a type error. It certainly goes beyond TypeError(Exception).

Is a '.close()' method being called twice a type error? It is in a language that can express states in the type system.

Is SQL injection a type error? It is when you use refined types in your sql library interface.

The vast, vast majority of errors I run into are errors that, with effort and the right type system, I could turn into type errors.

The point being that asking "would those be type errors?" is a really big question that is, when answered simply, "yes".

There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe. Maybe typescript is getting better.

Pyflakes and unit tests will detect the great majority of potential errors. Mypy gets you closer to zero.

Rust can express state machines just fine, as well as refinement types (Python can do refinement types too), but yes, I agree that there's room for languages to build more ergonomic but advanced type systems.

There are very usable, well-supported languages out there right now that do have such type systems. Saying they're out of consideration because they're not mainstream is a circular argument.

>Saying they're out of consideration because they're not mainstream is a circular argument.

No, it's a pragmatic argument. There's no circularity it.

If they're not mainstream, then they're neither "very usable" or "well-supported" to any extend that a mainstream language would be.

Here's the circularity:

- There are no mainstream languages with powerful and convenient type systems

- But there are less mainstream ones

- But I won't use those

- There are no mainstream languages with powerful and convenient type systems

That's circularity alright, but not as in a "circular argument" though. It's a feedback loop.

That's however a totally legitimate engineering choice.

Engineers picking on a language shouldn't bet on less mainstream incomplete environments with less tooling and libs and options and devs, just so that they can raise them into the mainstream.

That might be a "tragedy of the commons" thing, but it's not an engineering obligation to be an early adopter.

They're not obligated to by early adopters, but then you hear comments like:

> There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe.

And it's like, well there are great languages that can do that, but if you restrict yourself to that tiny 'mainstream' subset, you'll never know it.

And moreover I think engineers (or rather, companies) are way too conservative about this stuff–picking 'mainstream' tech can be a touch-and-go proposition at any time. Just because something is mainstream, doesn't mean it's the right choice for your project.

close() is partially handled by any language with scoped resources. There's lots of them.

Injections are handled by any language with taint, although that became less popular. Perl had it. Anything with typed orm also has something similar (for example Esqueleto in Haskell)

Both of those errors can also be addressed by better code, e.g. you can use lambdas to make sure things get autoclosed if there's no with/using construct. And you can avoid SQL injection by using query string interpolation instead of string concatenation, or parameter bindings.

I don't really see your point. Types can prove the absence of those bugs. "Writing good code" is not... anything.

Neither of the examples given need types if good interfaces to those functions are chosen. Since types are part of the interface then why wouldn't you just change the interface to not exhibit those bugs rather than using types to prop up a bad one?

How would an interface guarantee that close is not called twice, or that you have escaped a string exactly once?

I have rarely needed to escape a SQL string since the days of PHP4, nowadays it is standard to use parameter binding such as "SELECT * FROM table WHERE row = ?" - it's also faster since the query doesn't need to be recompiled every time, but if you really have a desire to escape SQL then you can write a string interpolation function that does it automatically e.g. sql_format("SELECT * FROM table WHERE foo = %s", s). Indeed, JavaScript supports this via custom templated string literals.

As for closing resources, you can use a pattern such as using(open("file.txt"), (f) => { ... }) if your language doesn't already support such a construct.

Escaping multiple times would be unnecessary with a type based system, by definition.

Sure, no one should need to do that anymore, it's just an example. There are many other cases that are similar, however.

`using` is a language construct, not something that is part of an interface. It also does not prevent close from being called twice.

In my case: Yes and yes. Wildly guessing, about 90% of the errors I find at runtime with dynamic languages would would be caught by a sane type system at compile time. If I'm comparing a completely mis-engineered statically typed language such as C++, the compilation overhead may be so bad that for code I'm writing right now feedback can still be faster with the dynamically typed language. But if we're talking interfacing a few bits of unfamiliar and not great dynamically typed code: well I've literally spent several weeks on a project that would have taken me half a day with even bad static typing.

Pyflakes and a test or two will weed out trivial errors right away. Getting to zero errors takes more work however and that's where mypy has a place.

Unfortunately tests in dynamic languages often don't help. I've run into too many issues where dependencies were mocked with parameters the dev thought were expected. (Or were expected in previous version of some library) With time, it all falls apart without real interface checks.

Mypy can apply to tests as well. I don't have any noticeably buggy Python programs and have written more than I can count. All this tooling is a great help but is no substitute for minimum of competence and attention.

It's when you want to add features to a codebase you don't understand, when these features shine.