14 ms·

All I want for Christmas is these seven TypeScript improvements

• eagsalazar2 4y ago
  Zod-like runtime parser/validator but built in and automatically inferred from type definitions so I can do MyType.parse(scaryUserInput).
• llimos 4y ago
  My wish list: - Type the default export in a single expression (issue #13626, open for 5 years) - Negated types. E.g. `string & not 'abc'`. `Exclude` only works for union types - Allow 'never' to take a type parameter that will show up in my IDE when a type resolves to it. 'never' is often used in more complex type construction, and if something is unexpectedly resolving to 'never' it would be nice to know which 'never' it is, a bit like an error message
• deterministic 4y ago
  A big YES for getting access to type information at runtime. We can’t trust the client. So all messages needs to be validated when received. I am currently doing this by code generating the protocol types and verification code from a custom spec file. It works but it’s a clunky way to do it.
• deleted 4y ago
  [deleted]
• eyelidlessness 4y ago
  I’m also excited for records/tuples, but I’d really happily settle for an intermediate “constAsConst” setting: as in if I assign a const, I’d like to be able to tell the type checker that it really is constant, that I don’t want to change any data in a collection type, essentially that it should treat the const keyword as an `as const` assertion. I’d have to fight with a bunch of other lint rules, but it’s what I mean ~99.999% of the time if I have my druthers.
  • ffhhj 4y ago
    They heard yer request yet kept immutable.
  • Waterluvian 4y ago
    Maybe I’m doing it wrong but when I try to handle this kind of thing, I get bitten by “readonly” and now I need to put readonly keyword in all kinds of functions. You’d think it could implicitly tell it’s readonly. Or maybe that’s a feature of my “pure” keyword idea.
    • eyelidlessness 4y ago
      As an obsessive readonly-er, yeah this pain is real. It basically colors your functions the way async does. There is a TS issue I haven’t checked on in a while about readonly-by-default and a corresponding mutable keyword. I doubt it got much traction, but it’s a shame. Writing Clojure I really liked that there was a baseline assumption that functions are pure and a clear signal in code when it’s stateful. It doesn’t have to color functions (but ahem it works great for Haskell), but it seems like a reasonable opt-in default that shouldn’t be so painful.
• chrismonsanto 4y ago
  TypeScript the language works well for me. All I really want is a more robust incremental mode, especially with respect to renaming or deleting files. I've been bitten enough by this that I blast the cache directory in my pre-push hook.
• Waterluvian 4y ago
  I just want the map, reduce, filter functions to be acutely aware of the narrowed types. The moment I use Object.entries and then work on the data, the key has been widened to string. Okay and maybe I also want it to be aware of type assertions that happened outside the array functions. You should already know that x cannot be undefined anymore. I tested that. I know you don’t think you can be sure you’re actually being called after the assertion, but you are! It’s obvious! Oookay and maybe just one more (sorry Santa!): I want a ‘pure’ keyword. Any function that is pure can only call functions that are also keyworded as pure. No side effects, guaranteed.
  • deleted 4y ago
    [deleted]
  • HellsMaddy 4y ago
    I love the pure function idea.
  • mpoteat 4y ago
    You can implement a type-aware map, reduce, filter, etc. if you use point free semantics with higher kinded types: https://code.lol/post/programming/higher-kinded-types/ https://code.lol/post/programming/higher-kinded-types/ I have to admit it's a bit heavy, but this is totally representible in today's Typescript if I understand your ask correctly. It would be great if it was a more obvious / automatic inference, though.
  • tadfisher 4y ago
    The opposite would be better: an "impure" keyword for specifying impure functions. Or maybe, you could pass some kind of "scope" interface that provides functions for executing side effects. So "impure(IO) function printStuff()" brings all the functions in IO into scope for the body of printStuff.
    • castrodd 4y ago
      Why would the opposite be better? Aren't most functions impure? The original proposal made sense to me, but I am curious as to why you believe impure is better. Can you elaborate?
• wruza 4y ago
  Most of that not gonna happen by ts ideology. But the reason why people need that is unclear to me. Typescript already is 99.9% typing improvement over javascript. Chasing that 0.1% out of pure perfectionism makes one an enemy of the good and of themselves. Please remember that these extends keyof and co were included in ts not because it’s so super cool with types. They are there to cover common dynamic patterns of existing js codebases and standards. You don’t have to make same mistakes again, and definitely aren’t expected to make this problem worse. There’s already enough popular projects with perfect multi-page meta-type gibberish instead of plain human-readable types. Which wouldn’t require rust-tsserver running on a supercomputer in the first place.
  • ajkjk 4y ago
    uh... people want them because they run into pain points every day, in a project that's actively developing and can solve those pains. Why wouldn't people want their pain points solved? They're not, like, rare issues. They happen every day, or at least every few weeks. A month can't go by without my putting up a code change that has "unfortunately, TS doesn't support this, so <workaround>" in the description. I love TS but it can certainly be better. edit/afterthought: I just do not care about JS-compatibility per se. It's a nice guideline but I'd like the language I use to be as good as possible, because I'm trying to use it to do things, regardless of their ideology.
    • wruza 4y ago
      Whatever they do, you’ll still have pain points, because people tend to ignore the good and focus on what’s left, and what’s left is never zero for that’s how the universe works. Gods run into pain points all the time. The correct question is not where our pain points are, but how far these pain points are from what we want to do, i.e. are these points a real pain or just our own perfectionist anxiety. Typing for the sake of typing may not help doing the job before thursday.
      • ajkjk 4y ago
        Yeah but when you fix this round of pain points and then people complain about the next one... then that means I got a bunch of improvements? Is your point "because you'll still have pain points after improving things, don't improve anything?" that makes no sense. In no sense are the issues with TS "perfectionist anxiety". They're real, fixable problems that make it harder to write safe or simple code.
• IAmLiterallyAB 4y ago
  It may be a rendering bug, but this page is incredibly frustrating to read on Firefox mobile, with the Buy the Book/ Subscribe banner sitting directly in the center of the screen when I scroll down.
  • rickstanley 4y ago
    Same for me. If you use uOrigin you can select and hide the element, but I didn't even bothered. Now I now I won't be visiting this site anytime soon, at least not on mobile.
• bhaney 4y ago
  Out of curiosity, what languages have type systems that can accomplish the "typed pipe" described in the article? There are plenty where you can specify a fixed number of arguments like (A -> B, B -> C), but how do you do that in a variadic context?
  • tonyg 4y ago
    Typed Racket, but you'd write the pipe operator as a trivial macro rather than as a function.
  • eckza 4y ago
    If the type of C is a type D -> E -> F... then you're already there. Or I'm misunderstanding the question. (In which case, please, somebody correct me.) But if I'm not... Elm, Haskell, F#, and probably most other FP langs support this.
    • bhaney 4y ago
      Sorry, I just realized that the pseudo-notation I was using to represent a partial type signature is similar to the actual type signature notation that Haskell and Elm use, so that's probably confusing things. What I specifically meant by "(A -> B, B -> C)" was "two arguments, each of which are unary functions, and the type of the argument accepted by the second function is the same as the the return type of the first function." I think in formal notation, the full signature would be "(a -> b) -> (b -> c) -> (a -> c)" but I'm not overly familiar with that notation so I may have gotten that wrong. The goal here is to be able to describe a function as mentioned in the article, that can accept any number of functions (either as varargs or a single list of functions), and ensure that the input of each provided function has the same type as the output of the function that precedes it.
      • consilient 4y ago
        Haskell can do this, although it's pretty unidiomatic: data AlignedFunctionList a b where Identity :: AlignedFunctionList x x Pipe :: (x -> y) -> AlignedFunctionList y z -> AlignedFunctionList x z pipe :: AlignedFunctionList a b -> (a -> b) pipe Identity a = a pipe (Pipe f g) a = pipe g (f a)
• chadlavi 4y ago
  These are all really weird and not idiomatic. Most of your weird quibbles would be solved by just writing a type like const pt: [number, number] = [1, 2] As for piping functions... that's just how functions work. Not sure what the point of that piping syntactic sugar is.
  • antonyt 4y ago
    It doesn’t have to be the only way that functions work. Pipeline operators are idiomatic in other languages, and the linked proposal in that section of the article is worth reading.
    • chadlavi 4y ago
      Sure, but not in JavaScript.
  • jonwest 4y ago
    I’m admittedly not primarily a TS dev, but I agree with your points completely. Even though you’re reading the piped functions right to left, and most code is going to be read from left to right, in order for a parameter to be passed like a value it’s gotta be computed. If I’m solving a math equation, I know that I need to follow the order of operations—I don’t need to rewrite the equation in an entirely new way. It’s more intuitive for me, at least, to wrap my head around the current approach.
    • bigDinosaur 4y ago
      It takes about thirty seconds to become used to writing nested function calls as a pipe - it's purely syntactic sugar. It's not what I'd call an 'entirely new way' in the sense that changes nothing about evaluation order or anything like that.
  • gforge 4y ago
    The pipe is one of those things that once you've tried it you never want to go back. The pipe came to R a few years back and I would argue that it is one of the best features. I admit that data munging is a very stepwise process but I find myself frequently missing it in Ts when I code. It makes the code denser as you use fewer intermediate variables while the code id still easy to debug.
• toastal 4y ago
  Tuple+Records would be huge. Pattern matching would nice too as well as a dense form to write tagged unions, but I want these things in JavaScript first and not just TypeScript.
• mpoteat 4y ago
  But you can type 'pipe' correctly in Typescript, without resorting to overloads: https://code.lol/post/programming/typesafe-function-composition/ https://code.lol/post/programming/typesafe-function-composit... It's even more powerful if you restrict yourself to point free semantics - then you can use higher kinded types to do generic-level variadic composition. As well, optional generics are trivially achievable in TS via default type parameters, unless I'm not understanding that section of the article.
  • Tade0 4y ago
    Good write up. I had a feeling some form of this must've been possible, especially that with newer versions of TS the compiler has become increasingly better at handling recursive types and doesn't throw the dreaded TS2589 error nearly as often.
  • modestygrime 4y ago
    > As well, optional generics are trivially achievable in TS via default type parameters, unless I'm not understanding that section of the article. He links to another post that goes into more detail: https://effectivetypescript.com/2020/12/04/gentips-1-curry/ https://effectivetypescript.com/2020/12/04/gentips-1-curry/ In particular the question and answer in the comments should make it more clear.
• ledauphin 4y ago
  the final request is a big advantage Python currently has over Typescript's otherwise dramatically superior type system. The utility of types at runtime for dynamic ser/de is huge for a lot of common application domains.
  • rosebay 4y ago
    [dead]
• Beltalowda 4y ago
  > The sluggishness of tsc remains a pain point for many developers tsc isn't just slow, it's SLOW. % : >file.ts % time tsc file.ts tsc file.ts 3.26s user 0.15s system 145% cpu 2.347 total 3.2 seconds is just embarrassing. Nothing is even close to this; every other compiler or interpreter is in the dozens or maybe low-hundreds of ms. clang++ -O2 and rustc are both ~150-200ms, and these are not compilers known for their excellent performance. The startup time of tsc is an order of a magnitude slower than anything else. I didn't measure lines of code/second performance, but with such a slow startup time it's not that important because no matter how small your project: typescript will be ridiculously slow. I don't want to run any "watchers" or special dev servers for the frontend or all of that ridiculously complex circus to work around this embarrassingly slow tooling. I just want to request "/file.ts" and have it serve a compiled version on the fly. This is simple, easy, and even with caching just a few lines of code. It's how everyone was using coffeescript back in the day. What we have now is millions of lines of code and a world of complexity to work around an embarrassingly slow compiler.
  • deleted 4y ago
    [deleted]
  • Gigachad 4y ago
    Is it really much of an issue? I work on a large TS project on a 2020 m1 MacBook and I’ve never been aware of the ts compilation. It seems snappy enough.
    • Beltalowda 4y ago
      > Is it really much of an issue? Yes, because I don't want to wait seconds every time I change a typescript file and I don't want to world of complexity to make it have the same performance every other compiler has out of the box. My "solution" for this is to not use typescript. I'd like to, but it's just too painful.
      • nawgz 4y ago
        So you are writing naked JS or what? A lot of developers decided slow compiles - I don’t know what pathological case you stumbled on to make a single file take 3s tho - is far superior to needing to suss out runtime errors, and I find it hard to believe you made the choice to write naked JS instead of TS. If you picked a different language, fair enough I suppose, but I have to admit I’m not that sure why someone would tap JS/TS if another language is equally suitable. I am a front end guy after all, so I don’t particularly have a choice
• jeffybefffy519 4y ago
  I dont use TS, just vanilla JS mostly. As a vanilla JS user, the pipe operator is much harder to understand from a first glance because its effectively a primitive being added to the language.
  • lf-non 4y ago
    There is a js proposal to add this to language: https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator There are few exceptions (namespaces, enums) but typescript has been quite averse to adding non-standard language level features outside type annotations. This feature will likely come to ts after this proposal has been accepted for js.
  • pharmakom 4y ago
    Firefox already supports the pipe operator. There is a Babel transformation for the pipe operator. However, TS does not support it, even as an experimental option.
• chucklenorris 4y ago
  I want actual reflection a la python so i can use my types to generate all sorts of artifacts for runtime validation, serialization, testing, etc. It's frustrating to make the effort to create the types and then not be able to touch them at runtime
  • janosdebugs 4y ago
    How would Typescript do that while transpiling to JS? It would need to add a whole lot of boilerplate code to the generated JS, slowing the execution down.
    • chucklenorris 4y ago
      Something like typeinfo<T> being inlined into an object describing my type. Totally opt-in, no need for every type to be tracked at runtime.
    • samtho 4y ago
      Does it not already do this? I don’t use TS if I have the choice due to all the runtime complexities, including the endless house-of-cards shimming it does to prop up all the features of TypeScript.
      • consilient 4y ago
        No, typescript has full type erasure and almost no type-directed emit. The shimming you're seeing is probably the result of tsc downleveling newer javascript features to older browsers: typescript itself has nothing to do with it. https://www.typescriptlang.org/tsconfig#target https://www.typescriptlang.org/tsconfig#target
      • janosdebugs 4y ago
        Try running tsc in ES2020 mode, the output will be surprisingly clean JavaScript. Older versions include a lot of hacks for dynamic module loading, etc.
  • esrch 4y ago
• realworldperson 4y ago
  [dead]
• deleted 4y ago
  [deleted]
• rosebay 4y ago
  All I want is nominal types, if this is possible already, somebody please let me know!!
  • goto11 4y ago
    Typescript does not support nominal typing except for enums. It can be emulated by giving types an unique property, but this is kind of a hack.
• nesarkvechnep 4y ago
  The pipe wish can be accomplished with a class. Not the most ergonomic but works well. You just need to explicitly cast `return <?, ?>this`.
  • choward 4y ago
    That means all the functions you are piping have to have the same return type (i.e return an instance of your class). Piping is more generic.
• repsilat 4y ago
  Does Flow do a better job of the tuple examples? I feel like it inferred types on variables without annotations quite well -- `x=[1,2]` being something you could pass to a function expecting `$ReadonlyArray<number>` or `[1,2]` or `[any, number]` or anything in between. I think the type on the variable is often something complex or narrow at the point of definition and getting progressively wider as it's used in various ways.
  • pharmakom 4y ago
    Flow is / was awesome but Microsoft killed it using VS Code.
    • repsilat 4y ago
      Yeah. I think typescript has better predicate functions, maybe a slightly worse behavior in most places, and Flow is much much faster. But all of those differences get swamped by the "everyone is using it" effect. Typescript "won" in some vague narrative/consensus sense, so we standardise on it, and we get the ecosystem benefit of types existing for every NPM package.
• jsf01 4y ago
  I’ve got many TypeScript Christmas wishlist items, too, but I have to admit I disagree with a few of these! A new syntax for tuples is overkill. TS is already getting quite syntax heavy and I feel that the current methods for defining tuples are more than adequate—either with “as const” as described in this post or like “const foo: [number, boolean] = [5, true]” as the TS docs recommend for tuples. Runtime type evaluation—please no! This is the perfect domain for libraries to exist in. When you import a library, it’s explicit what’s going to happen at runtime. Libraries are easy to debug, forkable, and swappable. Baking this behavior into the compiler not only foregoes those benefits, but also makes the output less easy to predict and will of course add overhead to the compile. My own wishlist top 3: 1. Better following of type narrowing through branches and functions. After I filter out all nulls in an array or prove that some optional variable is definitely not undefined, there are still times when ts can’t tell that that’s the case. I can force it to with workarounds, but wish I didn’t have to. 2. Compiler perf improvements. Hard to disagree with you there! Esbuild locally and tsc in ci is okay-ish, but not an ideal state for the ecosystem to stay in for the long term. 3. Consolidation of tooling. For node do you go with tsc and run the output? Or ts-node? Esbuild locally and tsc in prod? Deno? Browser-side, similar questions but throw in Vite and all the other options, too, and even for someone working in this environment regularly, setting up a new project with all the proper tooling is far too much effort.
  • CGamesPlay 4y ago
    > 3. Consolidation of tooling. For node do you go with tsc and run the output? Or ts-node? Esbuild locally and tsc in prod? Deno? Browser-side, similar questions but throw in Vite and all the other options, too, and even for someone working in this environment regularly, setting up a new project with all the proper tooling is far too much effort. I actually really agree with the last sentence, and think an officially endorsed set of projects would be pretty useful. The first part of your wishlist though, I don't think is a big issue. I'd say close to 100% of the people using a bundler are using tsc as a linter. Esbuild, babel-typescript, rollup, swc, these all strip TypeScript types and don't raise TypeScript errors at all. Those that aren't using tsc as a lint step are going to be directly running the output of tsc directly, given that the only way to not do this is ts-node, the documentation of which advises using tsc as a linter.
• croes 4y ago
  >did that red squiggle go away because I fixed the error, or because I'm waiting for tsserver to catch up? Shouldn't you know without red squiggle if you fixed something? That's like waiting for the red squiggle in Word to know if you spelled a word correctly.
  • madsbuch 4y ago
    when I see a an error I build a hypothesis about the error before reading into it. then I solve the hypothesized error and verify that it indeed was solved. this works in 9 out of 10 cases and is hugely effective - as long as the ls is fast. this is like branch prediction. better the faster you can verify that the branch you predicted was the right one.
• shakwp 4y ago
  Test comment
  • shakwp 4y ago
    Test Reply
• deleted 4y ago
  [deleted]
• pharmakom 4y ago
  Give it a few more years and every language will be OCaml :)
  • AnthonBerg 4y ago
    Hope to see you again at the Idris stop!, or will you be getting off the bus after everyone has turned into OCaml?
• captainmuon 4y ago
  The one thing I want is operator overloading, so I can write vector calculations in a natural way. But this would need differing behavior depending on types, which is something the developers don't want to add in principle. They say it has to be added in JS first, but this is something that makes not much sense in JS but is possible when you have type information at compile time. (You don't want to add the penalty of dynamic dispatch to every addition, just rewrite v1+v2 to v1.__plus__(v2) when you know statically that v1 and v2 are Vectors.) I thought about implementing it myself (maybe as a babel transformation) but I couldn't figure out a way to access the type information.
• simmschi 4y ago
  I'm a simple guy. Excess property checking not just on object literals would be a wonderful Christmas present.
• yakshaving_jgt 4y ago
  Yeah it would be great if TypeScript just became Elm.
  • bazoom42 4y ago
    Why? Cant you just use Elm if you prefer that? Typescript is specifically constrained by being a superset of JavaScript, Elm does not have that limitation.
    • yakshaving_jgt 4y ago
      I suppose I should have appended "/s". I find it amusing/sad that there is simultaneously reticence in adopting Elm and an eagerness to gradually copy all of its features as the JS crowd learn that typed pure FP isn't such a bad idea after all.
      • bazoom42 4y ago
        There are significant downsides to using a niche language.
        • yakshaving_jgt 4y ago
          Ok, and there are significant downsides to using JavaScript, so pick your poison.
          • bazoom42 4y ago
            That goes without saying :)
• deleted 4y ago
  [deleted]
• lairv 4y ago
  The only true thing that bothered me when using TS was the lack of pattern matching (the trick using the never type doesn't count), I can't believe a language with union types doesn't have a clean way to make exhaustive union discrimination
  • ahmedalsudani 4y ago
    One of the 5 stages of grief: bargaining :) I have tried to use a couple of tools with better types on the job and on the "productive/industry" side of the spectrum. That consistently led to disappointment. It's been a while since I gave up on TS; what drove me away then was the typings I had to download and update and debug. Nowadays I'm working on learning the purescript terrain for frontend development. In that world, the limitation is not the language but my ignorance. That feels better.
• rr808 4y ago
  Can we talk about grammar? I've noticed it is becoming normal not to use the plural 'are', this title is triggering for me. Even on primetime TV I'm hearing 'is' everywhere, does anyone else complain or am I just getting old?
  • rmccue 4y ago
    “All” is acting as a singular noun here, so the grammar is correct: https://www.grammarphobia.com/blog/2013/01/all-for-one.html https://www.grammarphobia.com/blog/2013/01/all-for-one.html
    • rr808 4y ago
      Damn now I'm triggered and confused. I'm not sure if I believe this, will have to look closer. Grammarly accepts either way.
  • JimBlackwood 4y ago
    Hah, funny! I genuinely did not notice until you mentioned it and I reread the sentence using ‘are’. Extra funny because I’ve been caught noticing myself using english plurals in my native language. (so for 'lantaarnpaal' the plural would be 'lantaarnpalen' but I’ve been saying 'lantaarnpaals') I guess it might just be how language evolves, it’s interesting to see it happen. I wonder if grammar books will ever adjust to these changes?
  • rajamaka 4y ago
    It's a play on the song "All I want for Christmas is you"
    • rr808 4y ago
      Nice, I'm grumpy about hearing that song every 5 minutes as well. :)
    • semireg 4y ago
      The original play might have been this 1947 classic All I Want for Christmas Is My Two Front Teeth. https://en.wikipedia.org/wiki/All_I_Want_for_Christmas_Is_My_Two_Front_Teeth https://en.wikipedia.org/wiki/All_I_Want_for_Christmas_Is_My...
• scrollaway 4y ago
  Are we doing wishlists? All I want is the possibility of doing nominal typing. Hrmph: https://github.com/microsoft/TypeScript/issues/364 https://github.com/microsoft/TypeScript/issues/364 - https://github.com/microsoft/TypeScript/issues/4895 https://github.com/microsoft/TypeScript/issues/4895
• scotty79 4y ago
  > Why doesn't TypeScript infer the type of square (and hence x) from its usage on the next line? Anders is famously skeptical of "spooky action at a distance" where changing code in one place can cause a type to change and produce errors in other places that aren't obviously related. I feel it in rust when current error spot jump wildly across all of my code as I'm fiddling trying to fix it or modify it. It's not pleasant, but funny when you fix the last few red spots in one place only causing the huge red bloom in far away place or red jumping back and forth between two far away places as you type.
• svrtknst 4y ago
  I've been bashing my head trying to create some sort of typed pipe for a while, with a syntax matching Elixirs, to avoid having to create curried functions all the time. The farthest I've gotten is that I achieve typing, so long as the function isn't generic. So this works: const plus = (a: number, b: number) => a + b; pipe(5) .thru(plus, 3) // Pipe(8) // ^---- this is inferred as `number` But this doesn't function plus<T extends string|number>(a: T, b: T) {/* ... */} pipe("five") .thru(plus, "three") // Pipe("fivethree") // ^--- this isnt inferred or narrowed,becoms `unknown` iirc
  • deleted 4y ago
    [deleted]
  • SebastianKra 4y ago
    Have you tried this: function doSth<A, B>(a: A, b: B): B { /* ... */ } function callFn<Args extends any[], Out>(fn: (...args: Args) => Out, ...args: Args): Out { /* ... */ } const foo = callFn(doSth, 'asdf', 'bsd' as const) // a: 'bsd' const bar = callFn(doSth, 'asdf') // error
    • svrtknst 4y ago
      I've tried something similar, but splitting the args into Head and Tail and extending the Parameters<F> of the input function and some other trickery Been a little while since I looked at it tho
• AnthonBerg 4y ago
  It is the nature of programming that we manipulate symbols. It is the nature of programming that there are tools that solve these problems. Tools that aren’t TypeScript but can be used on top of TypeScript. Exactly like TypeScript is to JavaScript.
  • the_sleaze_ 4y ago
    It is the nature of programming that the programmer will complain about just about everything, until it gets fixed. At which point the programmer will begin to complain about the fix anew.
    • AnthonBerg 4y ago
      A lot of the strands in the notice-understand-fix loop are simple transformations, almost mechanical – deterministic ones corresponding to a simple formal grammar underneath. As long as you can cleanly and concisely discuss and point to the symbols in question across programming scopes, and as long as the programming language is able to manipulate these scoped structures. TypeScript on top of JavaScript is one layer of this. Things like OCaml generating Javascript can be seen a higher layer as the OCaml type system is strictly more powerful and complete than TypeScript. Then dependently typed languages close a certain loop here, as dependent types are programs, and dependently typed compilers concisely and deeply capture this kind of program-in-the-program transformation.
• prmph 4y ago
  I just want higher-kinded types to be supported. There is an issue[1] about this which has been pending for 8 years. 1. https://github.com/microsoft/TypeScript/issues/1213 https://github.com/microsoft/TypeScript/issues/1213
• Rapzid 4y ago
  Two biggest quality of life improvements for me would be: Fixing very slow intellisense in VSCode when large numbers of types are imported. Such as from AWS SDK or CDK. Show resolved types ie {...A, ...B} vs A & B.. There are hacky workarounds that shouldn't be necessary. Issues open for years on both.
• pshirshov 4y ago
  The fun fact is: Scala can do all this (and lot more). And it can be compiled into JS through Scala.js. It doesn't require a runtime library and has decent interop with JS.
• ralusek 4y ago
  The only one I need from this list is optional generic arguments. The `satisfies` syntax from 4.9 was a huge win, and the `const` indicator on generic arguments coming in 5.0 is huge for me.
• zanethomas 4y ago
  Sounds like what you really want is c#.