Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 196 posts

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

#41

Post by jitl »

jedimastert wrote: post #18
phpnode wrote: post #9

Earlier quoted context omitted.

> The implementation isn't even that horrible You're making me blush! The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic. Might run into recursion limits though.

> The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic. Is that anything like church encoding? https://www.wikiwand.com/en/Church_encoding#/Church_numerals

Not really. In the Typescript type system tuple types are array types where the length is encoded in the type system. Tuple types can be “added” by concatenation to produce a new tuple type:

    type two = [0, 0]
    type three = [0, 0, 0]
    type five = [...two, ...three]
    type TupleToNumber = T[“length”]
    const num: TupleToNumber = 5

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

#42

Post by cjdell »

cuddlecake wrote: post #21
cjdell wrote: post #10

I had no idea you could compose string literal types AND infer variables using interpolation syntax in the context of conditional types. I am salivating at the potential use cases for this...

It's a new feature from TypeScript 4.1 (this version is yet in beta) https://devblogs.microsoft.com/typescript/announcing-typescr...

Lots of new toys to play with in this release! They've also explained each new feature really well...

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

#44

Post by smichel17 »

Merad wrote: post #33
PudgePacket wrote: post #25

Earlier quoted context omitted.

What do you mean by "no JS overhead"?

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.

This is why you need input validation. Eg, zod or io-ts.

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

#45

Post by williamdclt »

h0h0h0h0111 wrote: post #37
cjdell wrote: post #32

Earlier quoted context omitted.

I'm glad you asked. :-) For a start, number types. I want i32, i64, u32 etc. JavaScript (and therefore TypeScript) only has "number". Yes we now finally have BigInt but it's not ideal for JIT optimisation. Object prototypes is a weird part of JS that we really could do without. If you really want that, use class syntax. The Date object. Need I say more... Little things like Object.keys() should return a (keyof T)[] r…

Another potential benefit - runtime metaprogramming. All types are erased when converted to JS, but I can imagine a lot of utility for runtime types in Typescript.

Obligated mention of runtypes (https://github.com/pelotom/runtypes) that bridges the gap between type-land and runtime-land. It's not seamless at all but if you have a serious need for this sort of thing, it's great

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

#46

Post by ricksharp »

ricksharp wrote: post #12

Nice! I built something similar - A set of scripts that generate SQL statements from typescript types to wrap a PostgresSql db. It’s more a hybrid data structure where only relationships and certain fields become columns (which can be indexed and searched) and most of the other data becomes a Json column. I wasn’t completely satisfied with the final results, but it does at least allow me to add additional data fields…

Thinking about this more. I think this project has some promising practical uses when combined with code generation from the typescript ast (which is what my project does).

Since the type system can parse the SQL strings, then it becomes possible to include those strings as a source for the ast. Then the code generator can use the typescript parser to parse all the types and the sql. From that it can generate all the required code to create the runtime queries.

I don’t like ORMs because they make it very difficult to write complex queries (and my own attempt did not solve that very well - I still had to manually type any complex queries). However, if this could essentially allow writing a complex query in raw sql and have it type-checked at code-time, it becomes easier to use. Then the code generator would convert that into a type-safe runtime library which solves 2 problems: 1. The poor editor performance of the type system inferring so many nested types. 2. Actually having a runtime that executes the queries.

The outstanding problem would be migrations...

Anyway, this is certainly a thought provoking project.

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

#47

Post by franky47 »

Jweb_Guru wrote: post #35
bhouston wrote: post #27

Is typescripts type system becoming like c++ template meta programming?

TypeScript is more powerful in some ways.

Only in some: the fact that the type system can know everything it needs to generate runtime code, but chooses not to do so, is kind of frustrating sometimes.

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

#48

Post by akavi »

jitl wrote: post #41
jedimastert wrote: post #18

Earlier quoted context omitted.

> The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic. Is that anything like church encoding? https://www.wikiwand.com/en/Church_encoding#/Church_numerals

Not really. In the Typescript type system tuple types are array types where the length is encoded in the type system. Tuple types can be “added” by concatenation to produce a new tuple type: type two = [0, 0] type three = [0, 0, 0] type five = [...two, ...three] type TupleToNumber = T[“length”] const num: TupleToNumber = 5

Am I understanding this correctly that typescript provides a type-level property on tuples called `"length"`?

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

#49

Post by williamdclt »

soheilpro wrote: post #43

This is insane! Just curios, are there real-world use cases for stuff like this?

I could imagine working on very complex static JSON. You want to type-check selections and transformations on this JSON.

It's a very niche use-case, this is definitely more of an impressive showcase of the new Template Literal Types feature of TS :)

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

#50

Post by cjdell »

smichel17 wrote: post #44
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.

This is why you need input validation. Eg, zod or io-ts.

Did not know about these. I wrote my own a while back because I couldn't find an example of this being done (fully type safe validation).

https://github.com/cjdell/type-safe-validator

Post reply on HN