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

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[] is purely a TypeScript design decision, coming from how TypeScript chooses to model object subtyping [2].

  type Foo = {
    a: string
  }
  
  const keysOfFoo = (obj: Foo) => Object.keys(obj)
  
  const foo = {a: '', b: 5}
  keysOfFoo(foo)

The fact that this passes type checks is a conscious TS design decision that comes with both advantages and disadvantages. It wouldn't have to be this way; Exact types [3] could potentially be used to describe that if the type is exactly Foo, it's safe to assume Object.keys(foo) is (keyof Foo)[].

For first class tuples (and records), there's a stage 2 EcmaScript proposal coming along [4]. There's of course also the readonly [] type in TypeScript if you only need the safety of not accidentally pushing to an "immutable" array. First class language support could have nice additional features though, like strict equality.

Anyways, if these are the things you don't like about JS/TS, I don't think AssemblyScript will be the answer for you, as the goals of that language seem to be entirely different from "fixing" old JS cruft. Apart from the i32, i64 stuff I guess.

[1] https://github.com/tc39/proposal-temporal

[2] https://github.com/Microsoft/TypeScript/pull/12253#issuecomm...

[3] https://github.com/microsoft/TypeScript/issues/12936

[4] https://github.com/tc39/proposal-record-tuple

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 accidentally assigned by a normal string.

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

Little things like Object.keys() should return a (keyof T)[] rather than a string[] but can't due to JS edge cases.

This was something that confused me when I first started learning Typescript but is actually not an edge case but a fundamental feature of Typescript's structural typing.

A type T is only guaranteed to be at least (a subtype of) T. Which in the case of objects means it has at least those fields, but potentially more. For instance

  interface FooBar {
    foo: string
    bar: string
  }

  interface Baz {
    baz: number
  }

  const fooBarBaz: FooBar & Baz = {
    foo: 'foo',
    bar: 'bar',
    baz: 3
  }

  
  const printFoobar = (fooBar: FooBar) => {
    for (const key of Object.keys(foobar)) { 
      if (key !== 'foo' && key !== 'bar') {
        // If Object.keys was (keyof T)[] Typescript would claim this branch is unreachable
      } 
    }
  }

  printFooBar(fooBarBaz)

It's really worth thinking about Typescript types not as nominal objects like in Java or Haskell, but contracts about minimum functionality. Embracing this in terms of function arguments and return types makes testing and composing typescript code much easier. For example, if you were writing a AWS Lambda function in Typescript that only uses the body of the incoming event.

  export const handlerOne = (event: APIGatewayProxyEvent): Promise => {
    console.log(event.body)

    return {
      statusCode: 200,
      body: event.body,
    }
  }

  interface MinimalEvent extends Pick {}

  export const handlerTwo = (event: MinimalEvent): Promise => {
    console.log(event.body)

    return {
      statusCode: 200,
      body: event.body,
    }
  }

handlerTwo only requires a handlerTwo({ body: '....' }) call in a test, instead of having to fill in all the extra properties of the APIGatewayProxyEvent that aren't even required. You might be tempted to use a type coercion in the test instead e.g. handlerOne({ body: '....' } as APIGatewayProxyEvent) but the problem with the coercion is that is in not checked at all by the compiler, it's essentially like temporarily using an any type. So if handlerOne is updated in the future to depend on more of the structure of APIGatewayProxyEvent Typescript will be none the wiser that the test requires updating (although granted hopefully the test would fail).

Anyway, that's a long winded explanation of why Object.keys shouldn't return (keyof T)[]. If you want to program generically over the Type of something I'd suggest making use of a runtime type library like io-ts instead which gives you a data structure representing the type to iterate over, etc.

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

But I completely agree that TS right now has perhaps one of the best and most intuitive Type System than any other language.