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).
TypeScript 5.0
301–310 of 332 posts
Re: TypeScript 5.0
#302Without 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.
If Flowtype had more resources from Facebook it could still be the dominating language
Re: TypeScript 5.0
#303Earlier 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.
Re: TypeScript 5.0
#304Earlier 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.
> 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
#305Does anyone else find that Enum is just not worth using and you’re better off with union types?
https://devblogs.microsoft.com/typescript/announcing-typescr...
Re: TypeScript 5.0
#306Earlier 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.
Re: TypeScript 5.0
#307Earlier 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
Re: TypeScript 5.0
#308Earlier 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
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
#309Earlier 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.
Re: TypeScript 5.0
#310Earlier 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…
I do hope to try it maybe in recent future.