Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

251–260 of 332 posts

Re: TypeScript 5.0

#251

Earlier quoted context omitted.

One downside to having a version 4.10 is that some sorting algorithms put this release between 4.1 and 4.2 and not after 4.9. But yeah, they should just go ahead and follow semver from now on.

Python went from 3.9 to 3.10 some time ago. And many people with YAML-based pipelines found out that 3.10 is turned into decimal 3.1, and ended up trying to build with an ancient version, because quoting was optional (and because YAML is a terrible language).

Same with Go 1.20

https://twitter.com/caarlos0/status/1631635896393932801

Re: TypeScript 5.0

#252
Typescript is a good try, but ultimately our favourite JS runtime errors still happen, even with all the strictest ts settings. Syntactically it is quite clumsy, you can see the uninspired mix of C++ and Java in there. The typings now although people are doing lots of cute things with them, don't do some really fundamental things. For example there is currently no sensible way to type a non empty array in Typescript. Also the discriminated union with the identifying string literal in there is not terribly elegant.

Personally I wish either Rescript or Purescript gained adoption instead.

Re: TypeScript 5.0

#253
post #249

Has anyone found a way to get TypeScript to run directly in the browser without a build step since Microsoft removed the js files that did this? Basically, Is this following pattern still possible? If not, what typed language do people here use for buildless front-end dev? I REALLY want to move away from weak-dynamically-typed PLs.

You can use typescript as jsdoc annotations

Can you please expand further? If I annotated my js, how would the browser check and enforce my types? Would the checks include js-to-js code? What is the js script that I should include at the top of my ?

Re: TypeScript 5.0

#254
post #87

Earlier quoted context omitted.

I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…

You just described OCaml or StandardML. Or as others have said, F#, or maybe Scala. Or if you're feeling really brainy, Haskell. But Rust was, in its early days, basically inspired by the ML type system, its type inference model, and its pattern matching facilities. The first Rust compiler was written in OCaml.

Haskell doesn't (or didn't last time I tried it) have the documentation and example culture of Rust.

Re: TypeScript 5.0

#255

Earlier quoted context omitted.

Flow still has some better sides: * first class opaque type support * exact object type * correct variance, sound liskov oop * no transpilation support (/*: */ and /*:: */) - so simple, so powerful; jsdoc ts doesn't compare, you can't import type star, when consuming libraries you have to increase maxNodeModuleJsDepth and other shenanigans; in flow you simply have access to all flow type language; why they don't want…

Great list! Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs. This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwar…

In another plot twist TypeScript is supporting the Types as Comments TC39 proposal that would provide a true 0-transpilation workflow.

https://devblogs.microsoft.com/typescript/a-proposal-for-typ...

Re: TypeScript 5.0

#257
post #165

Earlier quoted context omitted.

for sure for sure. that's kinda the point though: they already were migrating... to Flow. Lots of big projects are on the list that had to change course later because TypeScript won: - Yarn - Jest - Luxon - Gatsby - Expo - Styled-Components - GitKraken - GraphQL-js and that's just off the top of my head. I'm sure there were many more.

Do you have the impression that Flow once had greater adoption than TypeScript, or that there was a movement from TypeScript to Flow? I think it was always behind in adoption, but of course, some projects used it anyways. From my memory, Flow always felt like the less conservative cousin and it was tempting to use it, but TypeScript always was the safer bet.

I have to disclose my potential bias here because I am these days very involved in the TypeScript world (with Michigan TypeScript). That said, I would never hide the fact that I was once a die-hard Flow person that.. died hard, haha. (and I'm very glad I did! more on that later)

In the very early days (in every circle I was in) Flow was ahead by every measure (known examples, excitement, adoption, features, speed, etc). You could point to real live running apps like GitKraken and Discord (hopefully my memory isn't failing me on those) that where shipping Flow very early. And you could use JSX! At the time there was literally no known project (especially OSS) actually shipping TypeScript. Not from Microsoft and not from anyone else. It was hard to tell if TypeScript was more of "embrace extend extinguish" (obviously with hindsight we can be absolutely certain that it wasn't that (unless we're talking about a decades long "long con" lol))

But there's something I could never have anticipated at the time that's more important to me today than any feature of the language:

The TypeScript team have done a breathtakingly amazing job of carrying the project through the years. TypeScript, as an open source project, is an absolute triumph: and I think it has everything to do with the people behind it.

At this point TypeScript is "good enough" in every way that really matters. If they consciously stopped developing the language and just focused on performance and bugs I think we should all call that a success. I really believe it's been handled _that_ well.

Meanwhile Flow went the other direction and there were bugs (in the 0.30 era, approximately) that had people pulling their hair out that were caused by the impedance mismatch of them making it for Facebook first and the rest of the world last. As far as I can tell, this really never changed (or at least, if it did, then maybe it was "too little too late").

Meanwhile, it seems like TypeScript has been managed with the literal opposite mindset: putting us in a situation where only one major project is left using Flow... React.

There are other projects like ESLint that have been... how do I say this in a not bridge-burn-y way... surprisingly reluctant to realize that TypeScript isn't some passing fad. But I'm confident that they're going to have their wakeup call sooner or later. The culture of JavaScript-land is just not loyal enough for gatekeeping a technology like TypeScript. Look at webpack. We all spent nights and weekends for years gaining knowledge on how it works and weeks per year getting familiar with it, then esbuild happened and we threw webpack away overnight like it never even happened. I believe the same fate awaits projects that deny the necessity of writing in TypeScript at this point in history, with the possible singular exception of React.

Re: TypeScript 5.0

#258
post #116

Earlier quoted context omitted.

Any links to their apologies? I don't understand why they apologized.

I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-...

yes exactly.

The only other context I'll add is for people shipping Flow that I knew at the time they felt that this announcement felt like it came about two years too late. I had already switched to TypeScript long before because, in part, of the things they're apologizing for in that article which were evident long before being said out loud. I say that with great reverence and respect for the people that worked so hard on Flow, by the way, but that's the situation I experienced.

Re: TypeScript 5.0

#259
post #87

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the…

I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…

> I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures.

This basically describes all of the recent ML – perhaps more specifically OCaml – influenced languages like Kotlin, Swift, F#. (Rust is also heavily influenced by OCaml but its distinguishing feature is manual memory management with lifetimes.)

I do wish we had a good Linux/Posix option with as good of a package manager as Rust's cargo. Kotlin and Swift have some support but are largely focussed on the JVM and MacOS respectively. OCaml itself is of course an option here but its syntax and smaller ecosystem is a stumbling block. Reason is an attempt at a more familiar syntax for OCaml but that community is mostly focussed on transpilation to JavaScript with ReScript.

Re: TypeScript 5.0

#260

Earlier quoted context omitted.

You’re basically describing Swift. Swift and Rust had a ton of cross pollination during their early years which led to those features developing similarly but memory management is a lot less targeted for extreme efficiency like Rust. Hopefully as the language continues to mature, the feasibility to use it outside of apple platforms also does because I really enjoy the language design.

Does Swift has pattern matching and equivalent of Option/Result enums? I tried it casually but the documentation didn't feel great and things felt like they assumed familiarity with Apple's ecosystem.

Patterns: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Optionals: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Result: https://developer.apple.com/documentation/swift/result

Post reply on HN