Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

SQL isn't type-safe, so Prisma has that over it if nothing else. There's also a lot to be said for the difficulty in composing efficient SQL queries. If this tool can do that (I would be surprised) it would be a significant advancement (yes, this would be "making you not learn SQL" in the same way C makes you "not learn assembly").

View on HN

SQL is as type-safe as the DB engine allows it to be. PostgreSQL is type-safe. Extracting these types and making them available and usable in your lang-of-choice at compile time is a different problem though.

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.

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.

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.

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.

Hmm, in what sense is SQL not type safe where this would be type safe, though? You could still use out of date client code connected to a DB that has had its schema change, no?

The DB and the code are not packaged together so is there even such a thing as compile time type safety?

Something like this would make sure that all queries are correct per some expected schema and processes keep the expected and live schemas in sync. Such a process might be "database migrations run in the CD pipeline and nothing else changes the database". Of course there are edge cases here and there (someone will eventually need to log into a production database), but these processes go a long way toward reducing risk.

Reply on news.ycombinator.com