Live data from Hacker News

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

github.com

31–40 of 196 posts

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

#31
post #22

Could someone ELI5? Actually, I wrote a lot of code in TypeScript and I know my SQL but I have absolutely no idea what is going on here.

Since you already know TypeScript, I think it is important to note that this project uses a new TypeScript 4.1 feature called Template Literal Types to do pattern matching in order to parse the SQL string.

https://devblogs.microsoft.com/typescript/announcing-typescr...

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

#32
post #23

TypeScript is becoming such a compelling language due to its insanely advanced type system (that allows for projects like this) that I now want to use it everywhere. I want it to become the next Python. I know Deno is supposed to be first class TypeScript but under the hood it's still a JavaScript runtime with all the baggage that comes with that. AssemblyScript is extremely interesting but last time I played with it…

What do you mean by "no JS overhead"?

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)[] rather than a string[] but can't due to JS edge cases.

Want first class tuples/immutable arrays.

Many other new syntaxes that can't be implemented due to the need for JS compatibility.

I'm sure there are others that I can't think of right now...

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

#33
post #23

TypeScript is becoming such a compelling language due to its insanely advanced type system (that allows for projects like this) that I now want to use it everywhere. I want it to become the next Python. I know Deno is supposed to be first class TypeScript but under the hood it's still a JavaScript runtime with all the baggage that comes with that. AssemblyScript is extremely interesting but last time I played with it…

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.

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

#34
post #26
post #11

Earlier quoted context omitted.

it's a bit fragile only due to my laziness, it could be done properly if this were a serious project.

How would it be done if done properly?

same mechanism, just deal with more edge cases. e.g. whitespace isn't really trimmed correctly at the moment, it doesn't handle escaping quotes in strings and so on. I did think about trying to match postgres's grammar but it's a lot of work and probably implementing a PEG first would make it easier.

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

#36
post #7

Earlier quoted context omitted.

yeah Typescript is compile-time-only type system, you can only use it as a type. still cool though

But if you declare a string literal as const, then the string runtime value will match the string type. So it would be possible to have a runtime result (that executes an actual db query for example) that is paired with the type result.

No, TypeScript is compile time only. There's no runtime type info.

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

#37
post #32

Earlier quoted context omitted.

What do you mean by "no JS overhead"?

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.

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

#40
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 reply on HN