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

101–110 of 196 posts

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

#101

Post by maple3142 »

mind-blight wrote: post #75
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…

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

Example:

  const x = { a: 1, b: 2, c: 3 }
  const y: { a: number, b: number } = x
  console.log(Object.keys(y))

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

#102

Post by tegeek »

erikpukinskis wrote: post #98
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 i…

Most typed languages work like this way. For example, Java compiles down to the bytecode. The JVM bytecode doesn't have preserve generics information. But Java code has generics so when it compiles down to the bytecode, it removes that information. This is almost true for all high level languages. Kotline's type system is very different than Java but it also compile down to the bytecode so Java and Kotline shares their libraries without sharing the type system. Type Script is no different. Only problem here is that Type Script doesn't bring its own "runtime" or libraries.

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

#103

Post by dwohnitmok »

erikpukinskis wrote: post #98
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 i…

Types do not need to have a one-to-one correspondence with runtime data structures and indeed in many type systems often do not. In the limit, a type does not need to have any runtime representation at all (this is more than just generic erasure or phantom type parameters, you can have an entire type signature that has absolutely no runtime representation of any of its parts).

There is not really a fundamental difference between types and static analysis.

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

#104

Post by zensavona »

erikpukinskis wrote: post #98
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 i…

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

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

#105

Post by bionhoward »

JavaScript is such a cool language, and I really love it, especially the FP subcommunity, but the AI community for Python is way bigger, I wish there were more options for neural nets, differentiable programming, and data frame type things in JS. The interoperability with WASM is hugely valuable, and so is the ability to easily publish results on the web. It feels like it’s way easier to make an AI system in python, but then you have to figure out how to monetize it, while if you use JS, you can build a web platform or service and monetize much easier. Thoughts?

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

#106

Post by primitivesuave »

Is this just storing data in memory and querying it with SQL?

I use DynamoDB Data Mapper in production (https://github.com/awslabs/dynamodb-data-mapper-js) - would be cool to see something like this for SQL. Effectively define a class with TS decorators to automatically generate tables and columns.

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

#107

Post by IggleSniggle »

inbx0 wrote: post #52
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…

For new code, I think most JS devs have already switched to using the class syntax. Also FP in JS is alive and well if you want to avoid dealing with prototype chains altogether. I think we can all agree the Date API sucks, but life can still be good if you just give in and include a date library. Also, there's some light at the end of the tunnel with Temporal proposal coming along [1]. Object.keys returning string[]…

That pull request from 4 years ago with regards to Object.keys is worth reading if you already or are considering writing a “type wrapper” for Object.keys, especially now that better tuple types have landed and string template types are coming.

Runtime types can still get you there. I’ve been happy with myzod for this purpose, which feels like writing TypeScript while getting you everything you need to validate at runtime in a very performant package.

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

#108

Post by IggleSniggle »

vorticalbox wrote: post #86
52-6F-62 wrote: post #55

Earlier quoted context omitted.

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

You should checkout myzod, which is very close to this experience.

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

#109

Post by yonixw »

primitivesuave wrote: post #106

Is this just storing data in memory and querying it with SQL? I use DynamoDB Data Mapper in production ( https://github.com/awslabs/dynamodb-data-mapper-js ) - would be cool to see something like this for SQL. Effectively define a class with TS decorators to automatically generate tables and columns.

https://typeorm.io/ support:

> MySQL / MariaDB / Postgres / CockroachDB / SQLite / Microsoft SQL Server / Oracle / SAP Hana / sql.js

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

#110

Post by dwohnitmok »

zensavona wrote: post #104
erikpukinskis wrote: post #98

Earlier quoted context omitted.

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

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 many ways. What perhaps makes Elm's type system seem advanced is that the runtime essentially never violates the guarantees of its type system, unlike Java (depending on your opinion of unchecked exceptions).

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.

It's also a bit weird to compare the languages because Typescript has a very different typing regimen than Haskell or Elm. Typescript is entirely structural while Haskell is almost entirely nominal and Elm is mostly nominal (with the exception of records).

Typescript has an extremely expressive type system. It is in fact so expressive I'm amazed that it's gotten so much adoption when languages like Haskell are still considered "advanced." I suspect it has to do with the semantics of the languages rather than the type systems.

Post reply on HN