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

Post by Wilem82 » Mon, Sep 28, 2020, 7:37 PM UTC

zamadatix wrote: post #123

Wilem82 wrote: post #115

Earlier quoted context omitted.

Are you really calling this ergonomic? https://github.com/codemix/ts-sql/blob/master/src/Evaluator.... Same thing but actually readable and maintanable would've been better implemented as a compile-time (build-time) script, basically source code generation.

Nobody said it's ergonomic to implement SQL in a type system. It was simply an answer to your question "What do you think is advanced about TS' type system and why?". It's advanced because you're able to implement SQL in types alone when with most languages you couldn't. The question on ergonomics is for the other languages where you can do this is it more or less ergonomic than this. Again that doesn't mean this IS…

Post by ricksharp » Mon, Sep 28, 2020, 7:48 PM UTC

johnghanks wrote: post #96

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.

Post by eyelidlessness » Mon, Sep 28, 2020, 7:53 PM UTC

thelazydogsback wrote: post #144

I love Typescript -- I just wish there were an alternate runtime (.Net core CLR/DLR or other) that offered shared-memory green and/or native threading for true support for embarrassingly parallel but not vectorized workloads. FWICT, I don't think Deno changes things here much. Typescript on the BEAM would be interesting to me as well.

Post by freeqaz » Mon, Sep 28, 2020, 8:14 PM UTC

alangpierce wrote: post #135

smt88 wrote: post #118

Earlier quoted context omitted.

From years of real-world experience, it's rare to run into types that are too complex to easily understand. The syntax is pretty easy to read, and the compiler and language service make it easy to navigate types, even if you haven't looked at the source for them yet.

FWIW I find that TypeScript types can sometimes be overwhelming or hard to decipher, especially some third-party library type definitions. The connect function from react-redux is one example: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d07d... Since types can get really complex, I feel a need to be conscious of avoiding complexity when writing types myself, unless the value is enough to justify a hard-to…

Post by dwohnitmok » Mon, Sep 28, 2020, 8:31 PM UTC

dllthomas wrote: post #146

dwohnitmok wrote: post #136

Earlier quoted context omitted.

Yeah you're right it's not a total order. I was being fast and loose and conveying a subjective feeling. RE row polymorphism, Typescript doesn't quite have what users of ML-like languages are asking for when they want row polymorphism (which is usually parametric polymorphism rather than subtyping). But it's close. As for convenient... well I'd argue by the time you've got the whole cornucopia of GHC extensions at th…

> RE row polymorphism, Typescript doesn't quite have what users of ML-like languages are asking for when they want row polymorphism (which is usually parametric polymorphism rather than subtyping). But it's close. How would you distinguish this from the following? function foo (x: T & {field: number}): T { ... } > As for convenient... well I'd argue by the time you've got the whole cornucopia of GHC extensions at the…

    function foo(x: T & {field: number}): T {
        return x;
    }
    
    function bar(x: T & {field: number}): T {
        const x0 = foo(x);
        // type error because x0 doesn't have field
        // would compile fine with row types
        const x1 = foo(x0);
        return x1;
    }