Show HN: A SQL database implemented purely in TypeScript type annotations • Hacker News Board

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

#71

Post by jakear » Mon, Sep 28, 2020, 2:26 PM UTC

akavi wrote: post #48

jitl wrote: post #41

Earlier quoted context omitted.

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"`?

To clarify, the "tuple" is just an array with fixed length. So ts isn't "providing" the length property, it's simply surfacing the underlying Array#length in JS, which it knows to be a constant.

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

#72

Post by cjdell » Mon, Sep 28, 2020, 2:26 PM UTC

jey wrote: post #56

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…

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

Ah yes. I looked at this a while ago. I liked it but then ran into a brick wall with a lack of support for an equivalent to async/await syntax. It has wrappers for JS promises but they are clunky and awkward, unless someone wants to enlighten me?

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

#73

Post by phpnode » Mon, Sep 28, 2020, 2:31 PM UTC

52-6F-62 wrote: post #55

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.

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.

A while ago I built this exact mechanism for Flow, it could be done in TypeScript if there was enough demand for it (it's rather a large effort) https://gajus.github.io/flow-runtime/

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

#74

Post by Wilem82 » Mon, Sep 28, 2020, 2:35 PM UTC

kingdomcome50 wrote: post #70

Wilem82 wrote: post #68

Earlier 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?

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.

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

#75

Post by mind-blight » Mon, Sep 28, 2020, 2:37 PM UTC

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…

What are the edge cases for Object.keys()? I've always wondered why that returned string[]

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

#76

Post by whatshisface » Mon, Sep 28, 2020, 2:45 PM UTC

james-mcelwain wrote: post #36

ricksharp wrote: post #19

Earlier quoted context omitted.

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.

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.

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

#77

Post by jey » Mon, Sep 28, 2020, 2:47 PM UTC

cjdell wrote: post #72

jey wrote: post #56

Earlier quoted context omitted.

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

Ah yes. I looked at this a while ago. I liked it but then ran into a brick wall with a lack of support for an equivalent to async/await syntax. It has wrappers for JS promises but they are clunky and awkward, unless someone wants to enlighten me?

Try this for some syntactic sugar: https://github.com/digitake/bs-promise-monad

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

#78

Post by ricksharp » Mon, Sep 28, 2020, 2:53 PM UTC

williamdclt wrote: post #64

ricksharp wrote: post #54

Earlier quoted context omitted.

Object.keys() is always frustrating. Also, the array access not returning an optional type (I wish there was a strict option for that) often gets me. We need a middle ground: “TypeStrict“ that can clean up some of the edge cases. If you need strict integers, you can create your own fake type: type Int32 = number & {__type:'Int32'}; I do this with strings sometime when I want a string subtype that can’t be accidentall…

For anybody interested in this technique: the googleable term is "branding". It's bringing some nominal typing into TS's structural typing

Cool, I never knew what that was called. Thanks!

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

#79

Post by phpnode » Mon, Sep 28, 2020, 2:55 PM UTC

Wilem82 wrote: post #74

kingdomcome50 wrote: post #70

Earlier 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.

all of the functionality happens at compile time

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

#80

Post by svieira » Mon, Sep 28, 2020, 2:59 PM UTC

ricksharp wrote: post #54

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…

Object.keys() is always frustrating. Also, the array access not returning an optional type (I wish there was a strict option for that) often gets me. We need a middle ground: “TypeStrict“ that can clean up some of the edge cases. If you need strict integers, you can create your own fake type: type Int32 = number & {__type:'Int32'}; I do this with strings sometime when I want a string subtype that can’t be accidentall…

In TS 4.1+ there _is_ an option for strict array access called `noUncheckedIndexedAccess` [1]

[1]: https://devblogs.microsoft.com/typescript/announcing-typescr...