Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

71–80 of 332 posts

Re: TypeScript 5.0

#71

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…

Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types.

Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature!

Want nominal types? No problem; just declare a field indicating the type name!

  interface Square { classRef: "http://example.com/Shapes/Square"; width: number; }
  interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; }
  type Shape = Circle|Square;
(I like to express things in a way that can be easily translated to RDF, hence my use of URIs for type and attribute names)

Since TypeScript types don't runtime checks, you can even do it on atomic types!

  type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" }
  type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" }
  
  const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error!  Try doing that in Java!  I OFTEN WISH I COULD

Re: TypeScript 5.0

#72
post #56

Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0

From the release notes, it certainly seems minor / backwards compatible.

> 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.

Re: TypeScript 5.0

#73
Probably an unpopular opinion, but my favorite thing about typescript is what it's done for the jsdoc community.

A bunch of stuff had to be built to support good tooling in vscode for types with JavaScript, and that was leveraged for jsdoc also.

I don't use typescript, but I benefit from it in multiple ways, js doc and the occasional .d.ts file have made my life better.

Re: TypeScript 5.0

#74
post #44

Earlier quoted context omitted.

My favorite usage for decorators in java is for defining http requests, it lets you write stuff like this @GET("/users/{id}") function loadUser(id: int): Promise {} @PUT("/users/{id}") function updateUser(id: int, user: User): Promise {}

Did't know Java had a `Promise` type

I didn't know Java had a `function` keyword.

That is TS, not Java. Not sure why the gp is calling it Java.

Re: TypeScript 5.0

#75
post #57

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…

That is a strange take. It sounds like you think the reason people don't use Typescript is because of performance and not what some would consider a irresponsible ecosystem of abandoned frameworks and a language that provides little actual safety while still being unpleasant to use.

It‘s not strange at all. I think them same. The type system of TypeScript is in practice much more useful than the one of C# or Java.

Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.

Re: TypeScript 5.0

#76
post #29

Earlier quoted context omitted.

I'm curious what criteria you used to pick Flow vs. Typescript.

I personally picked Flow because it was (and still is probably?) a much sounder and stricter type system than TypeScript. However, keeping up with the constant breaking changes (I helped maintained a few complex flow typedefs) led to me getting disenchanted and burnt out with Flow. Also, at one point a change was introduced where most (or all) internal errors would just cause a type to decay into `any`s, which frustr…

Flow is more sound in a lot of ways (e.g. exact object types, by default!) but it also has huge holes (e.g. it has no equivalent to --no-implicit-any, the single most important strict flag in TS). Neither is strictly more sound than the other.

Re: TypeScript 5.0

#77
post #70

It's easy to miss, but I'm most excited for "--moduleResolution bundler" ( https://devblogs.microsoft.com/typescript/announcing-typescr... ) My understanding is it should allow you to finally have TypeScript files that import other TypeScript files and include the file extension. This is important because, for one, it means Deno TypeScript modules and non-Deno TypeScript modules are now compatible (can import each ot…

FYI, I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for Deno", but I think what you want to do is the same thing I've been really irritated that I couldn't do before. Namely, I have an Nx monorepo full of standard TypeScript code, but that code works with a many things: Node, Electron, frontend apps with Angular or S…

Exciting!

It's weird to see this:

> commentary in the PR about this new mode being "definitely not suitable for Deno"

I wonder what they meant by that. I mean, this doesn't magically make all TS code Deno-compatible, but nobody expects it to. What it does do is remove by far the most ubiquitous (and silly) barrier to TS code being Deno-compatible. There are others- system APIs, http imports. But this change allows a whole lot of code that doesn't use those to become compatible

Re: TypeScript 5.0

#78
post #44

Earlier quoted context omitted.

My favorite usage for decorators in java is for defining http requests, it lets you write stuff like this @GET("/users/{id}") function loadUser(id: int): Promise {} @PUT("/users/{id}") function updateUser(id: int, user: User): Promise {}

Did't know Java had a `Promise` type

That's not Java. I believe they're demoing in Typescript a pattern they like from Java/Spring/Quarkus/Micronaut.

Re: TypeScript 5.0

#79

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…

AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.

Re: TypeScript 5.0

#80
post #56

Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0

From the release notes, it certainly seems minor / backwards compatible. > 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.

It does have some backwards-incompatibilities, but they're mostly minor/edge-cases
Post reply on HN