I think they implemented a generic nested language framework (whose real name eludes me).

same mechanism, just deal with more edge cases. e.g. whitespace isn't really trimmed correctly at the moment, it doesn't handle escaping quotes in strings and so on. I did think about trying to match postgres's grammar but it's a lot of work and probably implementing a PEG first would make it easier.

Not really. In the Typescript type system tuple types are array types where the length is encoded in the type system. Tuple types can be “added” by concatenation to produce a new tuple type:

    type two = [0, 0]
    type three = [0, 0, 0]
    type five = [...two, ...three]
    type TupleToNumber<T extends any[]> = T[“length”]
    const num: TupleToNumber<five> = 5

This is the complexity introduced when applying static types to a vanilla JS codebase, imo. It's easy to get crazy with types in vanilla JS. Adding Typescript forces you to resolve the different types explicitly and it can get hairy.

What this really demonstrates to me is the difference between starting with TS vs migrating to it. Code that has to think about the types the first time it is being built is going to be better structured, on average, than purely dynamic code.

Many complex/difficult to understand TS types exist precisely because the type system was too limited to express certain real world use cases without workarounds. As the type system takes on that complexity, and removes more limitations, it actually makes writing simpler types for those cases much easier.

This project does exactly that (TypeScript/PostgreSQL):

https://github.com/MedFlyt/mfsqlchecker

This particular feature is invented in ts, other instances of ts inventing a completely new thing are conditional types and mapped types. F# has type provider which is similar in some of its usages but different enough i dont think they're related.

As far as I understand (and I might be wrong so please correct me), this can't be used to generate anything. Of course all the technologies you've listed are useful and brilliant but this isn't what I'm seeing.

It's more of an experiment of thoughts to generate types that are defined by the result of the SQL query, bending a compiler to a new strange behaviour that happens to be SQL like.

A predicate is a computer program that accepts an input and returns "yes/no." A type system could be an arbitrary predicate which returns "well typed/not well typed" when given a term. But obviously there must be some difference between types and predicates, such as extensionality -- the type of an expression can be decided by examining the code alone.

> Like when the first parameter you pass to JQuery can be anything in the world: a DOM element, or collection of elements, or an object, or a function

That specific part is called overloading in OOP (java). Don't know about the rest.

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.

    function foo<T>(x: T & {field: number}): T {
        ...
    }

    function foo<T>(x: T & {field: number}): T {
        return x;
    }
    
    function bar<T>(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;
    }

This isn't strictly true, and @erikpukinskis has a point. Typed languages often do have type info that can make it to runtime. `typeof` -- virtually the only tool JS has for type reflection -- doesn't even compare to the richness of TypeScript. All of that richness is indeed lost in transpilation.

In C++, for example, we have `decltype`, `typeid`, type traits, RTTI, and so on -- all of which are available at runtime. Not to mention that in certain special cases, we also have the de facto storage of type information that makes it into binaries (e.g. discriminated union types).

Try this for some syntactic sugar: https://github.com/digitake/bs-promise-monad

don't get your hope too high it's just the intersection between the two, advanced typescript types are lost.

given it's just ocaml I don't think it can do this ever, not that it's necessarily a bad thing.

People downvoting an observation on a curious use of language? If it's because of some perceived political motive, then that's really sad.

I really did just wonder why anyone would anthropomorphize a programming language, by ascribing a gendered pronoun to it.

My native languages has gendered objects, and "language" is feminine. Might be the same case

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.

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.

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.

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

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.

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?

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.

> 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

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.

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

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

Why not make TS compile to LLVM?

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.

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.

Not sure if it makes it possible, but this is fun anyway: https://aphyr.com/posts/342-typing-the-technical-interview

What compile-time guarantees does that SQL library give? I don't see any docs or explanations at that Github repo and my TS knowledge is limited to be able to infer everything from a small code example.

      type EX = Query<"some query string", db>; 

    let names = (persons: EX1) => persons.map(person => person.name);

No, TypeScript is compile time only. There's no runtime type info.

  const sql = 'SELECT ...';
  type SQL = typeof sql; 
  // type SQL = "SELECT ..."