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!
Show HN: A SQL database implemented purely in TypeScript type annotations
81–90 of 196 posts
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#82Earlier quoted context omitted.
No, TypeScript is compile time only. There's no runtime type info.
The parent comment is saying that if you write the string twice, you can get the compiler to check #1 and the runtime to use #2.
Not exactly (there is no duplication), a string constant in typescript is it's own type:
const sql = 'SELECT ...';
type SQL = typeof sql;
// type SQL = "SELECT ..."Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#83This feels a bit like C#'s "Linq to Objects". Could actually be useful!
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#84Earlier quoted context omitted.
I'm honestly curious. What other languages have a type system the would allow for this project? That is, (a subset of) SQL as a type . And assuming these languages exist, are they as ergonomic to the developer as TS while instrumenting the above?
What compile-time guarantees does that SQL library give? I don't see any docs or explanations at that Github repo and my TS knowledge is limited to be able to infer everything from a small code example.
Maybe clicking on the playground link would help your understanding of the project. You can literally hover over the types defined like:
type EX = Query;
For example, add this below `EX1` (line 66) in the TS Playground:
let names = (persons: EX1) => persons.map(person => person.name);
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#85This 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 :)
You can import a json document directly into typescript and the entire document is a readonly constant type of the entire json object literal.
I've used this with a template JSON document that has an instance of all possible types in the runtime json.
Sometimes you might have to loosen the type slightly, but it works great for a quick start.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#86Earlier 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.
I was thinking about this the other day i would love for TS flag that would turn an interface into an assert
const shout = (message: string) => console.log(message)
into something like
const assert = require('assert'); const shout = (message) => { assert(typeof message === "string"); console.log(message); }
of course this doesn't work for more complicated types
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#87Earlier quoted context omitted.
Is this satire? What do you think is advanced about TS' type system and why? Duck-typing that creates a minefield instead of providing correctness? The unknown type that does the same? TS is a step forward from JS, but JS's bar is so infamously low that making something better isn't a big achievement, especially compared to other languages with normal type systems.
I'm honestly curious. What other languages have a type system the would allow for this project? That is, (a subset of) SQL as a type . And assuming these languages exist, are they as ergonomic to the developer as TS while instrumenting the above?
Not sure if it makes it possible, but this is fun anyway: https://aphyr.com/posts/342-typing-the-technical-interview
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#88Earlier 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…
Why not make TS compile to LLVM?
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#89Earlier 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…
What are the edge cases for Object.keys()? I've always wondered why that returned string[]
[deleted]
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#90That'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;