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.
I'm not entirely sure, but I suspect it's one of these programming "joke" where you take a concept and bring it far enough that it becomes ridiculous. So I'm guessing there's no real practical use case for this, and is a nice flex from the author. It would be nice if that were made dead clear in the Readme, something like "Why? Because it's fun"
Show HN: A SQL database implemented purely in TypeScript type annotations
161–170 of 196 posts
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#162Earlier 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…
Why not use a language that has the benefits of TS + everything you say and is designed to be independent from JS. I'm thinking of OCaml for example. Why not use OCaml rather than TS? Edit: Actually the idea is so obvious that you have ReasonML that can compile both to JS and assembly and is basically OCaml with a JS-like syntax: https://reasonml.github.io/docs/en/what-and-why Isn't that exactly what you're thinking…
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#163Earlier 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.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#164Nice! 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…
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#165Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#166 type Protocol = 'http' | 'https';
type DomainExtension = 'com' | 'org' | 'net';
type DomainName = 'example' | 'google';
type Domain = `${DomainName}.${DomainExtension}`;
type Path = string;
type ApiEndpoint = `${Protocol}://${Domain}/${Path}`;
This would seemingly get out of hand very quickly...Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#167Wow, I hope the typescript compiler is ready for this kind of dynamic complexity... type Protocol = 'http' | 'https'; type DomainExtension = 'com' | 'org' | 'net'; type DomainName = 'example' | 'google'; type Domain = `${DomainName}.${DomainExtension}`; type Path = string; type ApiEndpoint = `${Protocol}://${Domain}/${Path}`; This would seemingly get out of hand very quickly...
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#168Earlier quoted context omitted.
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...
This is fascinating! On one hand, as an old guard JS developer that upscaled to TS, I often find new TS syntax incomprehensible. On the other hand I am still slowly learning new concepts. Am I correct to assume these new concepts are imported from more advanced languages? Or are these invented in TS for TS?
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#169Could 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.
I'm not entirely sure, but I suspect it's one of these programming "joke" where you take a concept and bring it far enough that it becomes ridiculous. So I'm guessing there's no real practical use case for this, and is a nice flex from the author. It would be nice if that were made dead clear in the Readme, something like "Why? Because it's fun"
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#170TypeScript 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…
If you're impressed with TypeScript, you should definitely check out ReScript (formerly BuckleScript). Its type system is clean and sound, and yet compiles to native JS without overhead. https://rescript-lang.org/docs/manual/latest/introduction