Another potential benefit - runtime metaprogramming. All types are erased when converted to JS, but I can imagine a lot of utility for runtime types in Typescript.

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

> Want first class tuples/immutable arrays.

On this subject specifically, see the records & tuples proposal (currently at stage 2): 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.

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<APIGatewayProxyResult> => {
    console.log(event.body)

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

  interface MinimalEvent extends Pick<APIGatewayProxyEvent, 'body'> {}

  export const handlerTwo = (event: MinimalEvent): Promise<APIGatewayProxyResult> => {
    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.

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

Why not make TS compile to LLVM?

When you say doing without object prototypes -- are you advocating moving away from the entire prototypal inheritance model? Or just not exposing it?

Your requirements list makes me wonder why you want to stick with anything related to JS at all? With all the transpiling options, web assembly, etc.

Why not use a language that has the benefits of TS + everything you say and is designed to be independent from JS.

I'm thinking of OCaml for example. Why not use OCaml rather than TS?

Edit: Actually the idea is so obvious that you have ReasonML that can compile both to JS and assembly and is basically OCaml with a JS-like syntax: https://reasonml.github.io/docs/en/what-and-why

Isn't that exactly what you're thinking of?

This is why you need input validation. Eg, zod or io-ts.

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.

At the end of the day, if you look at a low enough level in the stack, there are no types. In a very concrete way, types are a high-level idea, and if the high-level stops matching the low-level, then bugs crop up.

See for example Tetris implemented in Pokémon Yellow via runtime code injection:

https://www.youtube.com/watch?v=Vjm8P8utT5g

Their compiler missed that!

So I think there's good reason to switch from talking about types as "assumptions", and think of them as compile time "assertions". Something lower-level in the stack could break the high-level code, but that doesn't make the high-level code useless, just imperfect.