Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

181–190 of 332 posts

Re: TypeScript 5.0

#181

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

god just think how good life would be if we had all switched to elm or reason instead.

there's not a day that goes by that I don't think about this

Re: TypeScript 5.0

#182
post #156

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

I remember this well, too. Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance stat…

Enums have been proposed for JS for quite a while (there was a sort of enum in "the lost version" ES4 and a TC-39 proposal stuck in Stage 0 for years now [1]). Enums have always had relatively simple JS output that resembles a somewhat common pattern in JS. It was a "standard", just never really a deeply adopted "standard".

What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.)

Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards.

[1] https://github.com/rbuckton/proposal-enum

Re: TypeScript 5.0

#183
post #172

Earlier quoted context omitted.

Have you tried C#? Sounds like it would fit your needs perfectly, additionally benefitting from a huge ecosystem behind it.

C# doesn't have algebraic data types and pattern matching though, right? I'm not the same person, but at least for me that's one of the big advantages of Rust, and it's one of those features that outside of Rust you only really find in ML-family languages. I know it's possible to simulate it partially using sealed classes in some languages, but that's always seemed like a lot of boilerplate in comparison.

Pattern matching was recently added to C#. I can't say quite how well it's been embedded into the language. I always hear great things about F#, ADTs, pattern matching, nice type system and it integrates nicely into the rest of the .NET ecosystem.

Re: TypeScript 5.0

#184

Earlier quoted context omitted.

That doesn't seem to address my concern. It seems like more of a curiosity. Whatever floats your boat.

How does it not address your concern? It’s quite literally making isInteger into a type guard. The ‘integer’ type above can passed to any place ‘number’ is needed.

  if (typeof s === 'number' && Number.isInteger(s)) {

Re: TypeScript 5.0

#185
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…

For me that's Kotlin.

It's my general purpose language. I also use Rust everywhere Kotlin isn't suitable.

Re: TypeScript 5.0

#186
post #84

The missing feature I want most is type narrowing across chained functions like: arr.filter(a => a.kind === „bar“).map(a => /* a should now be of type Bar just like in a branch */)

Wait, are you saying they added that in this release? That's awesome!

This is not part of this release.

Re: TypeScript 5.0

#187

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…

The jankiness of JS combined with the correctness of TS really is a powerful combo. Especially stuff like string keys and const arrays as enums make safe and readable code without a lot ceremony.

The big problem is the gap between TS and JS. User defined typeguards are a usable work around but it would be nice to be able to use a native isMyType function.

Also would be nice to have constraints natively in types. Like string lengths or max ints.

Re: TypeScript 5.0

#188
New decorators are so good.

I absolutely hated how the experimental ones worked and try to avoid using libraries that use it.

Re: TypeScript 5.0

#189

Earlier quoted context omitted.

How does it not address your concern? It’s quite literally making isInteger into a type guard. The ‘integer’ type above can passed to any place ‘number’ is needed.

if (typeof s === 'number' && Number.isInteger(s)) {

What do you expect me to do with this snippet provided with no context?

Re: TypeScript 5.0

#190
post #183
post #172

Earlier quoted context omitted.

C# doesn't have algebraic data types and pattern matching though, right? I'm not the same person, but at least for me that's one of the big advantages of Rust, and it's one of those features that outside of Rust you only really find in ML-family languages. I know it's possible to simulate it partially using sealed classes in some languages, but that's always seemed like a lot of boilerplate in comparison.

Pattern matching was recently added to C#. I can't say quite how well it's been embedded into the language. I always hear great things about F#, ADTs, pattern matching, nice type system and it integrates nicely into the rest of the .NET ecosystem.

F# is great. Simple, small, straightforward, great interop with .NET
Post reply on HN