Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

151–160 of 332 posts

Re: TypeScript 5.0

#151

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…

If performance is the only concern to pick a language, world is far simpler.

Re: TypeScript 5.0

#152

I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.

I think that TypeScript, properly managed with things like zod or typebox, does an excellent job of giving me those benefits of types that I've come to expect while also having a really, really first-class development experience that reminds me (unsurprisingly?) of how actually-delightful using C# was in its heyday, with ReSharper and Visual Studio making it enjoyable. I genuinely don't feel any hassle around using it; the way that I can start with type signatures and then make the red squiggles go away is a really comfortable way to write code for me.

For me, I was out of the JavaScript cinematic universe for a long time (from about 2011 to 2018) and TypeScript was my entree back in. What got me deeply into it, and has kept me there, is not that it's better than JavaScript, but that, for my purposes, it's better than my at-the-time common languages: Ruby, Java, and C#. It gives me most of the linguistic flexibility that I'm used to with Ruby, while preventing me from dealing with the worst thing about it (Other People's Ruby being high on my list of terrible things). At the same time, it provides a level of "fall into the pit of success" structure around the type system that's superior to Java or C#, while not being as difficult to access as Rust can be.

(I like Rust, too! But the level of experience and skill necessary for somebody to be a "TypeScript operator" remains low, while letting those folks leverage really nice tooling built by folks like me who write TypeScript tools and libraries.)

Re: TypeScript 5.0

#154

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…

> Without Angular, we may very well not have TypeScript today. Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal. Angular had zero influence in…

Typescript was born of JScript. Check the history and the docs.

Re: TypeScript 5.0

#155

I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.

I hope your editor supports TS.

Re: TypeScript 5.0

#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 state results in less opportunities to be more strict with typing.

Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.

Re: TypeScript 5.0

#157

Earlier quoted context omitted.

I don't think decorators being a proposal matters at this point. I know I've been using them for 5+ years now, and libraries such as NestJS already use them extensively. If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.

NestJS uses the previous, incompatible decorators implementation IIRC.

And, because it does so, you can fall down really deceptive holes due to the lack of typing around things that decorators apply to, like parameters.

I don't think that changes with stage 3 decorators, unfortunately. It makes NestJS really error-prone, in my experience, and it's a big reason I stopped making tooling for NestJS projects.

Re: TypeScript 5.0

#158
post #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…

Addendum to my nominal types: For the 'fake' nominal types (you can't put a symbol on a number!) I like to make those fields optional, which makes the type less of a lie. "If this number did have a [unit symbol] property, the value would be 'USD'". That will still prevent accidental USD CAD conversion, but allows converting to/from regular numbers without explicit casting.

A pile of thoughts on the subject from back when I first came up with it: http://www.nuke24.net/plog/32.html

Re: TypeScript 5.0

#159

Earlier quoted context omitted.

You can get around it pretty easily: const intSymbol = Symbol('integer') type integer = number & {[intSymbol]: never} const isInteger = (n: unknown): n is integer => Number.isInteger(n) function f(s: string | number) { if (isInteger(s)) { const allowed = s.toExponential() } else { // s still string | number } } With this you even get to define functions that must accept integers, which is kinda neat.

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.

Re: TypeScript 5.0

#160

Earlier quoted context omitted.

Have you tried Crystal? I got the same "oh, they got this right too" feeling about everything as well.

Crystal is excellent. I just can’t handle the sluggish compilation times. Has that improved?

Nope, but working with fewer/smaller dependencies (like Kemal) it seems more manageable. Also, the feedback from type system is much faster than the full build, so I've noticed I don't need to run the app to test every small change like I do with ruby. There is also an interpreter mode available for testing, but I haven't tried it yet since that currently requires building the language from source. I'm hoping the interpreter will solve that DX issue entirely once it's ready.
Post reply on HN