Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

291–300 of 332 posts

Re: TypeScript 5.0

#291

Post by a_humean »

WorldMaker wrote: post #171
a_humean wrote: post #105

Earlier quoted context omitted.

I remember doing a head to head comparison between Flow and Typescript back in 2015 or sometime around then, and flow came out top at the time. Main pull for flow for me was strict null checking and disjoint unions, which typescript lacked at the time. About a year later typescript got strict null checks and discriminated unions, and from that point on typescript just kept improving, the community type defintiions ke…

Typescript in strict mode doesn't allow excess properties in an increasing number of situations. Typescript is still more structurally typed than nominally typed so there's no easy way to opt-in a specific type to stronger checks than average. The ergonomics are obviously different between Typescript and Flow. There are existing practical workarounds today to get more "nominally exact" types in Typescript such as usi…

Those excessive property checks are pretty limited to basically the construction of object literals, and it does it because its normally an error if you have a very explict type but your literal expression doesn't match it. Typescript really does nothing to enforce anything around excess properties except for that narrow case.

Branding doesn't really enforce anything except what the user asserts is the case. Its not the same thing.

Re: TypeScript 5.0

#292

Post by prmph »

lmm wrote: post #232
prmph wrote: post #125

I wish MS will fork Typescript into a new language altogether that transpiles to JS or compiles to WASM. In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. My wish list for such a language (in addition to what is already in Typescript), in no particular order: - Generic object literals (Why sh…

> In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. Have you tried Scala.js? It's pretty much what you're asking for - a first-class functional language with all the things you'd expect from that, with compile-to-JS as something that works and feels fully first-class (and good integration wit…

Scala.js seems interesting, and I will look into it more. But if it is so nice, why hasn't it taken off like TypeScript?

Re: TypeScript 5.0

#293

Post by lmm »

prmph wrote: post #292
lmm wrote: post #232

Earlier quoted context omitted.

> In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. Have you tried Scala.js? It's pretty much what you're asking for - a first-class functional language with all the things you'd expect from that, with compile-to-JS as something that works and feels fully first-class (and good integration wit…

Scala.js seems interesting, and I will look into it more. But if it is so nice, why hasn't it taken off like TypeScript?

Scala was traditionally a backend language (and has a bit of an image problem, and some genuine community politics troubles), and isn't so well known on the front end side. I do believe it's genuinely the best language going though.

Re: TypeScript 5.0

#294

Post by iainmerrick »

awestroke wrote: post #289
iainmerrick wrote: post #247

Earlier quoted context omitted.

One thing I wonder is whether a “strict mode” subset of TS could be compiled to efficient code. Disallow “any” and most of the dynamic and meta programming features of JS so it’s fully typesafe. The type system is really nice, so even without being able to use the full range of JS hacks and escape hatches, I think it’d still be a nice language to work in.

TS by itself is not fully sound which could complicate such a compiler. Example: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLI... In the example above, the problem is that typescript allows casting function types to omit optional arguments, and also allows using a function with n arguments as a value where a function with >n arguments is expected

Yes, those sorts of loopholes would need to be closed. I was imagining a subset of the language, but there might need to be some breaking changes to cover cases like that. Maybe it would end up being so different that it would be an entirely different language? I don't know! But it's hard for me to accept that non-soundness in TS is necessary for TS itself rather than just an unfortunate consequence of the JS language and library that it has to build on top of.

Re: TypeScript 5.0

#295

Post by truth_seeker »

dimitropoulos wrote: post #2

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…

Yep. Frameworks play an important role in end user (developers) helps deliver software as quickly as possible.

Just like without Rails framework, we may very well not have Ruby today.

Also, without WordPress, we may very well not have PHP today.

Re: TypeScript 5.0

#296

Post by epolanski »

munbun wrote: post #270
epolanski wrote: post #205

Earlier quoted context omitted.

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

this looks like a better documented io-ts

The author is the same of io-ts and t-comb, but capabilities go well beyond io-ts (including the experimental modules).

Being able to generate types, encoders, decoders, apis, guards and even arbitrary data is extremely powerful.

Re: TypeScript 5.0

#297

Post by iainmerrick »

hatuthecat wrote: post #212
spion wrote: 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.

I do really like Swift, but isn't it usually significantly slower than Rust?

Swift seems more in the Go or Java class, rather than being competitive with C/C++ like Rust is. If that's so, Swift is still appealing as a pretty-fast, safe language with a much more sophisticated type system than Go or Java. But... TypeScript is too!

I have a feeling in terms of raw performance, JS is probably closer to Swift than Swift is to Rust. The important difference between Swift and JS isn't performance as much as which platforms/APIs/languages they can integrate with.

(Maybe I'm underestimating Swift's performance, though, or overestimating JS -- corrections welcome)

Re: TypeScript 5.0

#298

Post by iainmerrick »

epolanski wrote: post #205
treis wrote: 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

At first glance this looks similar to Zod (which is listed as an influence). What does @effect/schema do differently/better?

I feel like the name could use a bit of work for a start! "schema" is way too generic.

Re: TypeScript 5.0

#299

Post by [deleted] »

postdb wrote: post #281
kaba0 wrote: post #224

Earlier quoted context omitted.

> C# is currently lightyears ahead of Java in every way Let’s not claim things that can’t be objectively proven. C# does have much more features than Java, but that is not necessarily a plus in case of a programming language. There are features that are definitely better, but I am not bought that the whole would be. Plus, ecosystem-wise Java is much bigger and much more open-source. The runtime is also better on the…

Also C# is really meant to run on MS servers (Azur). Yes you can compile C# asp core projects on Linux, but the hell of dll when the there are many projects in a solution is quit annoying. Development experience in C# without Visual Studio is quite cumbersome.

[deleted]

Re: TypeScript 5.0

#300

Post by illiarian »

postdb wrote: post #283
illiarian wrote: post #150

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).

> Deno supports vastly superior threading model (such as green threads)

Whatever it supports, Javascript-the-language has no concept of threads. And workers are basically external processes with a somewhat awkward event-based communication and certain limitations.

Whatever Deno uses internally to implement them has no bearing.

Post reply on HN