Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

Yes, when we talk about type safety, we generally mean "compile time" type safety. Python is also "type safe" at runtime (which is to say, "it's strongly typed"), but we don't conventionally consider Python to be type-safe.

View on HN

Well, all I am saying is that PostgreSQL provides you with compile-time type-safety when your write your queries.

Bringing this type information at "compile-time" into your language of choice where you embed your queries can also be done but is a harder problem. There is good progress in that sphere but it is still in it is infancy.

The GraphQL eco-system for example, has this figured out using code generators. A similar thing can be done with DBs.

That depends on who you generally talk with. Dynamic typing/static typing are orthogonal to eg weak/strong typing and other type system features, that's estabilished terminology.

Nothing in your post contradicts mine, but you're using a contradictory tone, so I'm confused. Dynamic/static typing are indeed orthogonal to weak/strong typing; however, the OP seemed to be arguing that "SQL is typesafe because it is statically checked at runtime/JIT-compile-time" which is almost exactly the definition of "strong typing" and not generally what we mean by "type safe" (the latter typically refers to statically typed).

I think you misunderstood my point. You mentioned that "SQL isn't type-safe", which is NOT true. Any decent RDB engine allows to perform typechecking and validation of your query without executing it. This means that SQL is typesafe at compile time.

Fair enough. This is a small consolation for practitioners, especially since much SQL is often composed dynamically, and the engine can't tell you about where the composition went wrong (unlike Rust, TS, etc). Maybe if SQL had its own hygienic macro language, but I'm not sure how that would compare to libraries like Prisma.

python is type-safe if you use python3 and avoid the dynamic parts of the language using a linter.

Since it does no checking of the annotations at runtime: I don't really think this is accurate. This prints `5` for instance: https://repl.it/repls/DarkorchidFailingComputationalscience

    def do(s: int) -> str:
      return 5
    print(do("123"))

Python is duck-typed. Wrong types aren't detected until they fail to quack correctly.

If you run mypy or pyre-check on the code above, it'll give you a type error, just like a C compiler would.

Sure, but that's like saying "valgrind exists, so C has out-of-bounds checks". It doesn't. External tools have just found ways to add optional safety that the language lacks.

Reply on news.ycombinator.com