Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

301–310 of 332 posts

Re: TypeScript 5.0

#301
post #283

Earlier quoted context omitted.

Neither of those are proper threads, and they have various limitations placed on them. And the language and the VM has been, and will be for any foreseeable future, single-threaded.

Deno supports vastly superior threading model (such as green threads). Again depending on what you are coding, threading may not be the best model. Look at Ngnix vs Apache (event driven vs threading).

JFYI, apache httpd has had a similar event-driven request processing module for about 10 years, maybe more.

https://httpd.apache.org/docs/2.4/mod/event.html

Re: TypeScript 5.0

#302

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…

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

Flow was (and still is) awesome as a concept, but its main problem was that it felt as a side-project, which was supported for internal Facebook cases, but not really for open-source. TypeScript (back then) was a simpler language, but had a lot more manpower, which resulted in faster bug-fixes and more coverage of libraries.

If Flowtype had more resources from Facebook it could still be the dominating language

Re: TypeScript 5.0

#303
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’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.

Agree. I feel like rust and swift will eventually converge with time, with swift providing more and more static guarantees and lifetime-related keyword, and rust improving its ergonomics. ( although recently swift definitely also went a completely different direction, adding as many concept as possible to the language)

Re: TypeScript 5.0

#304

Earlier quoted context omitted.

It's not the same decorators that existed before that were added. They don't have the same features. The new one are based on the upcoming EcmaScript decorators.

Also, Angular relies on parts of the "experimental" decorators that these Stage 3 decorators do not support, so Angular likely will continue to use the "experimental" compiler flag for some time to come, with the added twist that some uses of decorators will now also compile without the flag but will exhibit different behavior and won't run correctly, which may cause all sorts of new headaches for Angular developers.

I just posted this in our FE channel at work

> Note that the ECMAScript decorator spec now supported in TS 5 doesn't support decorating method arguments, unlike the experimental decorators TS has had an that Angular uses e.g. @Inject, @Self, @Optional etc. I'm guessing that this is part of the motivation behind the inject() function, where you can pass flags to it as a second argument to support cases like self or optional - it gives them a path to moving to the new-style decorators in the long-term.

AFAIK argument decorators are only used for constructors, and that usage can be replaced by using inject() with flags, so a migration would be possible even today - although I'm sure there would be plenty of as-yet uncovered subtle implementation quirks!

The obvious headache TS 5 will introduce is that failing to follow a decorator name with () will now attempt to treat e.g. Inject as a new-style decorator and cause a type error of some kind, which is likely to be confusing. I'm guessing the Angular compiler will have to do something to manage this, even if it's just ensuring there's a useful error message.

Re: TypeScript 5.0

#306

Earlier quoted context omitted.

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

Don't worry - the Twitter web team also made this mistake. But they made it at a time when TS was popular instead of earlier when the two were equally popular. Even well after TS was clearly the better option (as in 2022) the twitter web team opposed anything being done in Typescript like separate modules that would be a dependency of the web repo. At least you recognize the better direction now.

With how much respect I have for TS now (its close to the gold standard in several categories for me), that would be a..... frustrating setup for me these days. TS just gets so much right, and is really a pleasure to work with IMO.

Re: TypeScript 5.0

#307
post #187

Earlier quoted context omitted.

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…

You can do all you list with effect-ts/schema. Arguably the highest quality TS lib out there. https://github.com/Effect-TS/schema

The sibling post illustrate the problem. Lots of different libraries in this area and hard to know which one to pick. Also just kind of seems wrong to use a library for types in a language that is for types only.

Re: TypeScript 5.0

#308

Earlier quoted context omitted.

If s is a non-integer number

I mean, that could be changed. Currently: either string OR number Possible: either string | number OR just number

> The OR doesn't indicate | in TypeScript, it indicates the result of the possible future type guard.

Are you implying in your other comment (that HN won't let me reply to) that Typescript has an "OR" operator that is distinct from "|"? Can you link to documentation on that?

Re: TypeScript 5.0

#309
post #266

Earlier quoted context omitted.

Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter

There was AngularDart, don't know what happened to it.

Publicly it's dead, but it's alive and well and constantly getting updated inside Google.

Re: TypeScript 5.0

#310
post #166

Earlier quoted context omitted.

How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.

Recent versions of C# have expressly been working to minimize/eliminate verbosity. Things like namespace statements (rather than { } blocks), global usings, top-level statements, record types (by default structurally compared, immutable data structures defined often only by their constructor and nothing else), and much more. Similarly recent libraries such ASP.NET have been working hard to use more of these things to…

Thank you for such a well written and detailed response. Gave me a fair representation of C#.

I do hope to try it maybe in recent future.

Post reply on HN