10 ms·

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 everyw

by cjdell 6y ago

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 concluded it wasn't yet ready for anything serious, or is that no longer the case? A first class TypeScript runtime with no JS overhead would be a dream come true. I just hope it happens someday, or that other type systems get these amazing features.

Wilem82 6y ago
Is this satire? What do you think is advanced about TS' type system and why? Duck-typing that creates a minefield instead of providing correctness? The unknown type that does the same? TS is a step forward from JS, but JS's bar is so infamously low that making something better isn't a big achievement, especially compared to other languages with normal type systems.
- kingdomcome50 6y ago
  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?
  - Wilem82 6y ago
    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.
    - phpnode 6y ago
      all of the functionality happens at compile time
    - kingdomcome50 6y ago
      Maybe clicking on the playground link would help your understanding of the project. You can literally hover over the types defined like: type EX = Query<"some query string", db>; and see the that the type as defined by the TS language server (i.e. in your editor) is the result of "running" the query without actually running the code. It's a little insane and somewhat akin to "type providers" in languages like F#. For example, add this below `EX1` (line 66) in the TS Playground: let names = (persons: EX1) => persons.map(person => person.name); Now change the column alias in `EX1` to something other than "name" and see what happens. You see that? There is now a compile-time error.
  - rimliu 6y ago
    Not sure if it makes it possible, but this is fun anyway: https://aphyr.com/posts/342-typing-the-technical-interview https://aphyr.com/posts/342-typing-the-technical-interview
  - Wilem82 6y ago
    Are you really calling this ergonomic? https://github.com/codemix/ts-sql/blob/master/src/Evaluator.ts 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.
    - zamadatix 6y ago
      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.
      - Wilem82 6y ago
        This thread made me read about conditional types in TS and in general more about its type system. I was ignorant. I agree now that it's advanced. Previously I only heard bad things about it without bothering to study it myself. Turns out, it's not all bad, there is some good as well. Still wouldn't want to work with it, ever; but that's beside the point.
      - kingdomcome50 6y ago
        Well said. It's amusing imagining the soup that would result from attempting to do this sort of thing in various other languages!
    - kingdomcome50 6y ago
      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
jey 6y ago
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 https://rescript-lang.org/docs/manual/latest/introduction
- phpnode 6y ago
  I don't think even ReScript can do this (yet?)
  - nsonha 6y ago
    given it's just ocaml I don't think it can do this ever, not that it's necessarily a bad thing.
- tegeek 6y ago
  TS compiled to JS without any "overhead". This is not what the OP said.
- cjdell 6y ago
  Ah yes. I looked at this a while ago. I liked it but then ran into a brick wall with a lack of support for an equivalent to async/await syntax. It has wrappers for JS promises but they are clunky and awkward, unless someone wants to enlighten me?
  - jey 6y ago
    Try this for some syntactic sugar: https://github.com/digitake/bs-promise-monad https://github.com/digitake/bs-promise-monad
- chrischen 6y ago
  Just want to add that the genType project can even compile ReScript to Typescript!
  - nsonha 6y ago
PudgePacket 6y ago
What do you mean by "no JS overhead"?
- akmittal 6y ago
  Probably running raw TS not TS -> JS -> Compiler flow. Running TS directly will have lots of performance benefits. Compiler will know the types and can optimize better.
- cjdell 6y ago
  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)[] rather than a string[] but can't due to JS edge cases. Want first class tuples/immutable arrays. Many other new syntaxes that can't be implemented due to the need for JS compatibility. I'm sure there are others that I can't think of right now...
  - ricksharp 6y ago
    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.
    - inbx0 6y ago
      Good news, safe array access is coming in TS 4.1 https://devblogs.microsoft.com/typescript/announcing-typescript-4-1-beta/#no-unchecked-indexed-access https://devblogs.microsoft.com/typescript/announcing-typescr...
    - 6y ago
tegeek 6y ago
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.
- dynamite-ready 6y ago
  Interesting referencing a programming language as a feminine article like that... Not saying it's wrong, just unusual to me.
  - dynamite-ready 6y ago
    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.
    - bmarkovic 6y ago
      They're probably a native speaker of gramatically gendered language (like German, most Slavic languages etc).
  - bruh2 6y ago
    My native languages has gendered objects, and "language" is feminine. Might be the same case
aszen 6y ago
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 excited about their advanced and complicated features.
- throwanem 6y ago
  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 that you find to be JS-bound. My experience with TypeScript gets deeper every day, but I haven't yet run into anything that was obviously only necessary because TypeScript is a layer over Javascript. I'd appreciate the benefit of some additional perspective there.
  - aszen 6y ago
    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.
erikpukinskis 6y ago
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 is a perfect example of how far that can be taken. But I think it’s important to realize how this differs from a strongly typed, compiled language. A language like Go doesn’t just need to know you’re passing an “array of structs with attributes x, y, and z” for fun. It actually uses that information to generate a binary. The types are not just a check that happens before the real compiling begins, they are how the compiler thinks about structuring the executable. I would love if a compiler expert could chime in here, but my understanding is you could never write a Typescript compiler that was “strongly” typed because there is no data structure that can efficiently represent arbitrary types like “4 Or An Object With An Attribute Set To 4” in any meaningful way. These kinds of “wacky types” are things you can statically analyze but not really “compile” per se. That’s why it’s a good fit for being transpiled down to a language with no types at all. TL;DR, TypeScript is not really a “typed programming language”, it’s a static analysis tool. It’s not really designed to “run”.
- tegeek 6y ago
  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.
- dwohnitmok 6y ago
  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.
jariel 6y ago
TS is really getting Ninja with typing. The ultra expressiveness of TS may not be a virtue. It may simply encourage us to be creatively academic with our designs, and do novel, non-obvious and hard to understand and maintain things in the code. With some of the newer TS releases, I can hardly fathom through the release notes why such a complex degree of metaprogramming has utility for anyone, and what kind of corner cases people must be diving into. They are actually quite hard to follow, and I find myself trying to parse through the need for such a thing, literally unable to conceive of an example use case. Perhaps without a strict philosophy such as they have in Go, the designers just go on ahead and implement their favorite intellectual exercise, or something that helps them with a task in the TS compiler itself, which may not generalize very well.

by cjdell 6y ago

Wilem82 6y ago

Is this satire? What do you think is advanced about TS' type system and why? Duck-typing that creates a minefield instead of providing correctness? The unknown type that does the same? TS is a step forward from JS, but JS's bar is so infamously low that making something better isn't a big achievement, especially compared to other languages with normal type systems.

kingdomcome50 6y ago
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?
- Wilem82 6y ago
  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.
  - phpnode 6y ago
    all of the functionality happens at compile time
  - kingdomcome50 6y ago
    Maybe clicking on the playground link would help your understanding of the project. You can literally hover over the types defined like: type EX = Query<"some query string", db>; and see the that the type as defined by the TS language server (i.e. in your editor) is the result of "running" the query without actually running the code. It's a little insane and somewhat akin to "type providers" in languages like F#. For example, add this below `EX1` (line 66) in the TS Playground: let names = (persons: EX1) => persons.map(person => person.name); Now change the column alias in `EX1` to something other than "name" and see what happens. You see that? There is now a compile-time error.
- rimliu 6y ago
  Not sure if it makes it possible, but this is fun anyway: https://aphyr.com/posts/342-typing-the-technical-interview https://aphyr.com/posts/342-typing-the-technical-interview
- Wilem82 6y ago
  Are you really calling this ergonomic? https://github.com/codemix/ts-sql/blob/master/src/Evaluator.ts 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.
  - zamadatix 6y ago
    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.
    - Wilem82 6y ago
      This thread made me read about conditional types in TS and in general more about its type system. I was ignorant. I agree now that it's advanced. Previously I only heard bad things about it without bothering to study it myself. Turns out, it's not all bad, there is some good as well. Still wouldn't want to work with it, ever; but that's beside the point.
    - kingdomcome50 6y ago
      Well said. It's amusing imagining the soup that would result from attempting to do this sort of thing in various other languages!
  - kingdomcome50 6y ago
    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

jey 6y ago

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 https://rescript-lang.org/docs/manual/latest/introduction

phpnode 6y ago
I don't think even ReScript can do this (yet?)
- nsonha 6y ago
  given it's just ocaml I don't think it can do this ever, not that it's necessarily a bad thing.
tegeek 6y ago
TS compiled to JS without any "overhead". This is not what the OP said.
cjdell 6y ago
Ah yes. I looked at this a while ago. I liked it but then ran into a brick wall with a lack of support for an equivalent to async/await syntax. It has wrappers for JS promises but they are clunky and awkward, unless someone wants to enlighten me?
- jey 6y ago
  Try this for some syntactic sugar: https://github.com/digitake/bs-promise-monad https://github.com/digitake/bs-promise-monad
chrischen 6y ago
Just want to add that the genType project can even compile ReScript to Typescript!
- nsonha 6y ago

PudgePacket 6y ago

What do you mean by "no JS overhead"?

akmittal 6y ago
Probably running raw TS not TS -> JS -> Compiler flow. Running TS directly will have lots of performance benefits. Compiler will know the types and can optimize better.
cjdell 6y ago
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)[] rather than a string[] but can't due to JS edge cases. Want first class tuples/immutable arrays. Many other new syntaxes that can't be implemented due to the need for JS compatibility. I'm sure there are others that I can't think of right now...
- ricksharp 6y ago
  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.
  - inbx0 6y ago
    Good news, safe array access is coming in TS 4.1 https://devblogs.microsoft.com/typescript/announcing-typescript-4-1-beta/#no-unchecked-indexed-access https://devblogs.microsoft.com/typescript/announcing-typescr...
  - 6y ago

tegeek 6y ago

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.

dynamite-ready 6y ago
Interesting referencing a programming language as a feminine article like that... Not saying it's wrong, just unusual to me.
- dynamite-ready 6y ago
  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.
  - bmarkovic 6y ago
    They're probably a native speaker of gramatically gendered language (like German, most Slavic languages etc).
- bruh2 6y ago
  My native languages has gendered objects, and "language" is feminine. Might be the same case

aszen 6y ago

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 excited about their advanced and complicated features.

throwanem 6y ago
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 that you find to be JS-bound. My experience with TypeScript gets deeper every day, but I haven't yet run into anything that was obviously only necessary because TypeScript is a layer over Javascript. I'd appreciate the benefit of some additional perspective there.
- aszen 6y ago
  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.

erikpukinskis 6y ago

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 is a perfect example of how far that can be taken. But I think it’s important to realize how this differs from a strongly typed, compiled language. A language like Go doesn’t just need to know you’re passing an “array of structs with attributes x, y, and z” for fun. It actually uses that information to generate a binary. The types are not just a check that happens before the real compiling begins, they are how the compiler thinks about structuring the executable. I would love if a compiler expert could chime in here, but my understanding is you could never write a Typescript compiler that was “strongly” typed because there is no data structure that can efficiently represent arbitrary types like “4 Or An Object With An Attribute Set To 4” in any meaningful way. These kinds of “wacky types” are things you can statically analyze but not really “compile” per se. That’s why it’s a good fit for being transpiled down to a language with no types at all. TL;DR, TypeScript is not really a “typed programming language”, it’s a static analysis tool. It’s not really designed to “run”.

tegeek 6y ago
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.
dwohnitmok 6y ago
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.

jariel 6y ago

TS is really getting Ninja with typing. The ultra expressiveness of TS may not be a virtue. It may simply encourage us to be creatively academic with our designs, and do novel, non-obvious and hard to understand and maintain things in the code. With some of the newer TS releases, I can hardly fathom through the release notes why such a complex degree of metaprogramming has utility for anyone, and what kind of corner cases people must be diving into. They are actually quite hard to follow, and I find myself trying to parse through the need for such a thing, literally unable to conceive of an example use case. Perhaps without a strict philosophy such as they have in Go, the designers just go on ahead and implement their favorite intellectual exercise, or something that helps them with a task in the TS compiler itself, which may not generalize very well.