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

91–100 of 196 posts

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

#91

Post by Justsignedup »

bartq wrote: post #90

That's pretty neat. What I really want is this: function fn(query:string){ const stuff = // do some stuff with `query` variable return createType(stuff); } type MyType = FromJS ; This way we could compute types on the fly with JavaScript instead of creating monstrous types in TypeScript types system.

wouldn't that be neat...

However, there are Java frameworks that basically generate a type system from your database so whatever columns you query ends up being static types that can be determined at compile time. https://www.jooq.org/

Java is really quite cool. I wonder if we'll ever get a typescript version of jOOQ

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

#92

Post by NieDzejkob »

Justsignedup wrote: post #91
bartq wrote: post #90

That's pretty neat. What I really want is this: function fn(query:string){ const stuff = // do some stuff with `query` variable return createType(stuff); } type MyType = FromJS ; This way we could compute types on the fly with JavaScript instead of creating monstrous types in TypeScript types system.

wouldn't that be neat... However, there are Java frameworks that basically generate a type system from your database so whatever columns you query ends up being static types that can be determined at compile time. https://www.jooq.org/ Java is really quite cool. I wonder if we'll ever get a typescript version of jOOQ

Similar libraries are also available for Rust, see diesel [1] or sqlx [2].

[1]: https://diesel.rs/ [2]: https://crates.io/crates/sqlx

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

#93

Post by bartq »

Justsignedup wrote: post #91
bartq wrote: post #90

That's pretty neat. What I really want is this: function fn(query:string){ const stuff = // do some stuff with `query` variable return createType(stuff); } type MyType = FromJS ; This way we could compute types on the fly with JavaScript instead of creating monstrous types in TypeScript types system.

wouldn't that be neat... However, there are Java frameworks that basically generate a type system from your database so whatever columns you query ends up being static types that can be determined at compile time. https://www.jooq.org/ Java is really quite cool. I wonder if we'll ever get a typescript version of jOOQ

I think we eventually will be able to evaluate JS in context of types and return whatever we want even asynchronously. Now we have some combinators given by TS authors which allow us to compose some limited set of computations. I don't know how Java does it, but I hope TS will do it better :-)

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

#94

Post by alangpierce »

Great project, really expands what feels possible with the new improvements in TS 4.1.

I wonder if this strategy could also be used to have strongly-typed GraphQL queries without the need to have a type generation step that you run separately. Currently when using GraphQL with Apollo, it's great that you get types corresponding to all queries, but having to run the type generator and maintain types in __generated folders is definitely an extra hassle.

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

#95

Post by gmac »

I'm interested to see if I can use these new template string type features to add more/better type checking and inference to my TS Postgres library[1]. My suspicion is that the TS recursion depth limit of 50 might limit this rather seriously.

[1] https://jawj.github.io/zapatos/

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

#96

Post by johnghanks »

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…

> I built something similar - A set of scripts that generate SQL statements from typescript types to wrap a PostgresSql db.

If you think these are similar I don't think you understand what this is / what it's actually doing.

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

#97

Post by aszen »

cjdell wrote: 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…

I'm a bit torn on whether an advanced type system like TS produces better api designs for libraries or whether it promotes bad designs that need advanced typings to be safe and sound.

I feel typescript is in many ways closely tied to JS because many of the advanced typing features don't make sense outside of existing javascript patterns.

We all talk about simplicity so what makes type systems different that we get excited about their advanced and complicated features.

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

#98

Post by erikpukinskis »

cjdell wrote: 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…

I’ve only been writing TypeScript for about a year, so I might be getting something wrong, but here’s my understanding...

I’m not sure your request fully makes sense. TypeScript is extremely expressive. You can specify basically any type you what... stuff like “The Number 4 Or A Function That Returns The Number 4 Or An Object With Any Attribute Which Is Equal To 4” and TS will just work with that.

This SQL compiler is a perfect example of how far that can be taken. But I think it’s important to realize how this differs from a strongly typed, compiled language.

A language like Go doesn’t just need to know you’re passing an “array of structs with attributes x, y, and z” for fun. It actually uses that information to generate a binary. The types are not just a check that happens before the real compiling begins, they are how the compiler thinks about structuring the executable.

I would love if a compiler expert could chime in here, but my understanding is you could never write a Typescript compiler that was “strongly” typed because there is no data structure that can efficiently represent arbitrary types like “4 Or An Object With An Attribute Set To 4” in any meaningful way.

These kinds of “wacky types” are things you can statically analyze but not really “compile” per se. That’s why it’s a good fit for being transpiled down to a language with no types at all.

TL;DR, TypeScript is not really a “typed programming language”, it’s a static analysis tool. It’s not really designed to “run”.

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

#99

Post by [deleted] »

cjdell wrote: post #32
PudgePacket wrote: post #25

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…

[deleted]

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

#100

Post by ballenf »

cjdell wrote: post #32
PudgePacket wrote: post #25

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…

When you say doing without object prototypes -- are you advocating moving away from the entire prototypal inheritance model? Or just not exposing it?

Your requirements list makes me wonder why you want to stick with anything related to JS at all? With all the transpiling options, web assembly, etc.

Post reply on HN