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

121–130 of 196 posts

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

#121

Post by aszen »

mattgreenrocks wrote: post #117
aszen wrote: post #97

Earlier quoted context omitted.

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 ex…

> 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. Well, I'd argue the type system surfaces the pain faster than the untyped variant. In the untyped version, you have to read the code to see that, "it's either the number 4, or a function which may produce the number 4." Once you see y…

I agree on type systems being helpful, my point was about immensely flexible type systems like TS which don't force any usual constraints of designing with sound types. I do appreciate a good sound type system that constraints the behavior of my code in well expected ways.

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

#122

Post by dynamite-ready »

tegeek wrote: post #60
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 had been thinking that WebAssembly or CLR could be the target for TypeScript and that would allow to bring her own base class libraries etc. But if you look closely again, the beaut & wide adoption of TS is because it has no "runtime" or no extra libraries or APIs to learn. Its the JS. This also makes it easy to iterate quickly on Type System and bring new features. Having its own runtime means, that wouldn't be ea…

Interesting referencing a programming language as a feminine article like that... Not saying it's wrong, just unusual to me.

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

#123

Post by zamadatix »

Wilem82 wrote: post #115
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?

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 ergonomic it's about finding a language with a powerful type system that could do it MORE ergonomically.

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

#124

Post by kingdomcome50 »

Wilem82 wrote: post #115
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?

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.

Yes. What you don't see it that the TS language server provides things like autocomplete, definitions on hover, squiggly lines, sane error messages, etc. to the developer as they write the parsing code. What you don't see is that because that file compiles, it is guaranteed to parse (certain) "SQL" strings into types. This is because the code doesn't have to actually run to work, rather, TS's powerful type system does the parsing.

Source code generation wouldn't really provide the same end-user ergonomics and, frankly, would barely resemble the same project. How would that work? You generate source code from a SQL string and a data source? At that point you might as well just... write the actual code. The point of this package is that type information is dynamically assigned according to arbitrary "SQL" queries at compile-time[0].

Have you gone through short exercise I outlined below? Surely you can't think it would be better to manually generate type information than have it automagically available and enforced instantly as you work?

The closest thing I've seen to this is "type providers" in F#. Where, given a database connection, a "Provider" can offer compile-time contracts between your code and the schema of the database. What it does not do is provide contracts against arbitrary projections of the database (SQL queries). Of course one can write code that queries and transforms the data in a type-safe way, but these "transformations" must happen in F# for the compiler to infer any new types.

This project takes the above to a different level and infers the type of the result of an arbitrary (subset of) SQL operation before it is ever executed. It's fairly impressive.

[0] This has been pointed out more than once already, but this project does offer compile-time guarantees

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

#125

Post by nikki93 »

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.

Interestingly this is something you can do in Zig with its `@Type`. Zig's compiler can eval (some) Zig code at compile time, this code can produce new types, and you can mention those types anywhere types are normally mentioned.

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

#126

Post by nikki93 »

phpnode wrote: post #15
ralusek wrote: post #14

I'm viewing this on my phone, so maybe I'm missing something, but isn't this getting all of its typing information from you explicitly declaring a result set `as const`, and then subsequently doing `typeof` that const value? How does that help in real world queries, where the result sets are dynamic? Also, how does it help beyond just naturally declaring a result set as const without the use of this library?

oh let's be clear there's no sensible real world use cases of this thing. it's a demonstration of what TS's type system can do

One use case of something similar is generating a regular expression matcher at compile time for example. This is what the C++ library https://github.com/hanickadot/compile-time-regular-expressio... does.

There are a lot of uses of compile-time code. One I have been interested in is generating bindings to other languages or generating serialization code, or even generating bytecodes for VMs with specific bytecodes for accessing your native data structures (instead of adding a level of indirection).

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

#127

Post by aszen »

throwanem wrote: post #113
aszen wrote: post #97

Earlier quoted context omitted.

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 ex…

My experience has been that complex APIs will be complex whether they're statically typed or not. It's always possible to add accidental complexity to a design, but an essentially complex problem domain necessitates an essentially complex solution. If that solution includes a static type system, then the type system needs to be at least as complex as the domain. I'd be interested to hear more about the TS features th…

Sure, let me start with a disclaimer, I have used TS briefly and found it great but I personally prefer Elm's type system.

My understanding is TS was designed specifically to statically type existing JS patterns in popular libraries and frameworks and while that's great, newer libraries rarely need such flexibility if they aim for type safe designs from the start.

When I use typescript I often get the feeling there are multiple ways of typing the same function, which is reasonable given that one of TS goals was to embrace the JS ecosystem and that meant covering multiple overlapping use cases.

Consider Enums and Union types in TS, at a higer level both express the same thing (this value can be one of these sets of values) but in practice there is lots of discussion on when to use which. I have not seen sum types (as they are usually called) being implemented in two different ways in other languages.

I think one of the ways to think about TS is that it was designed to help programmers better understand their JavaScript code by adding types while reinforcing their designs in a safe manner so if TS didn't have to interface with existing JS code many of the cool tricks it's picked up would not be useful I think.

Finally on the point of expressivity, I'm interested to know how TS helps in modelling application logic to make invalid state impossible.

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

#128

Post by kingdomcome50 »

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…

Well said. It's amusing imagining the soup that would result from attempting to do this sort of thing in various other languages!

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

#129

Post by ricksharp »

svieira wrote: post #80
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…

In TS 4.1+ there _is_ an option for strict array access called `noUncheckedIndexedAccess` [1] [1]: https://devblogs.microsoft.com/typescript/announcing-typescr...

Awesome!

I was just searching for that and all I could find were old github issues saying it was working as intended.

Thank you!

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

#130

Post by dllthomas »

dwohnitmok wrote: post #110
zensavona wrote: post #104

Earlier quoted context omitted.

I don't really know anything, but isn't this how Haskell and Elm work? With similarly expressive type systems?

There's a general mismatch between popular conceptions of type system expressiveness and actual type system capabilities. Elm has a very simple type system. In fact it is very close to having among the simplest type systems in any statically typed programming language (the only things that really set it apart are tagged union types and record types). For example Java has a much more expressive type system than Elm in…

> Haskell has a much more expressive type system than Elm, but still lags behind Typescript unless you turn on a truly gargantuan number of extensions.

IIUC: it's not a total order, Haskell (even '98) has things TypeScript doesn't[0], and TypeScript has things that Haskell (even with extensions) doesn't[1].

[0]: eg. higher-kinded types [1]: eg. (convenient) row polymorphism

Post reply on HN