Show HN: A SQL database implemented purely in TypeScript type annotations

Post by ralusek » Mon, Sep 28, 2020, 6:11 PM UTC

tobyhinloopen wrote: post #40

ralusek wrote: post #14

I'm viewing this on my phone, so maybe I'm missing something, but isn't this getting all of its typing information from you explicitly declaring a result set `as const`, and then subsequently doing `typeof` that const value? How does that help in real world queries, where the result sets are dynamic? Also, how does it help beyond just naturally declaring a result set as const without the use of this library?

This project allows you to query (transform) type definitions as data to create new type definitions using SQL. Dynamically transforming types could be useful to generate complex types based on other complex types. This project takes it to the extreme by adding an SQL interface to it

Post by svieira » Mon, Sep 28, 2020, 6:18 PM UTC

UhDev wrote: post #132

I think that TypeScript is nice but I would never touch a database running on javascript.

Post by alangpierce » Mon, Sep 28, 2020, 6:51 PM UTC

smt88 wrote: post #118

flowerlad wrote: post #81

This shows how complex TypeSript has become. It may be fun to write complicated Type annotations such as this, but imagine having to read and maintain the code!

From years of real-world experience, it's rare to run into types that are too complex to easily understand. The syntax is pretty easy to read, and the compiler and language service make it easy to navigate types, even if you haven't looked at the source for them yet.

Post by mypalmike » Mon, Sep 28, 2020, 6:58 PM UTC

52-6F-62 wrote: post #55

Merad wrote: post #33

Earlier quoted context omitted.

Can't speak for the GP but my single biggest complaint about TS is how it's basically a massive set of assumptions layered on top of JS. If the JS types at runtime don't align with your assumptions in TS, the whole house of cards can come crashing down.

Which is the nature of the compiler. It maintains the promise that what you're writing is still JavaScript—in that you could just strip all the type annotations and have valid JS. But I would love runtime checks for types. Even if that was a compiler step I could flag on—but that makes it a great deal more complex both to implement and reason about, likely—without starting fresh anyway.

Post by wolfgang42 » Mon, Sep 28, 2020, 7:14 PM UTC

mypalmike wrote: post #137

52-6F-62 wrote: post #55

Earlier quoted context omitted.

Which is the nature of the compiler. It maintains the promise that what you're writing is still JavaScript—in that you could just strip all the type annotations and have valid JS. But I would love runtime checks for types. Even if that was a compiler step I could flag on—but that makes it a great deal more complex both to implement and reason about, likely—without starting fresh anyway.

Why do you need runtime type checks if the compiler already checked the type? IMO, runtime type analysis is a code smell. There are few scenarios where the simpler and more efficient solution involves querying type metadata at runtime. Particularly in a language that directly supports dynamic dispatch, you should think hard before adding anything resembling an "if typeof(mything)" check.