Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

321–330 of 332 posts

Re: TypeScript 5.0

#321
post #315

Earlier quoted context omitted.

web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...

You still need to run JavaScript functions to manipulate the DOM. "without ever touching JS/TS" seems misleading as that implies "no JavaScript code is executed".

When I read "touched" I don't think "executed". I think "edited". There is C code executed when I run JavaScript, but that doesn't mean that I had to touch it. Similarly, all the JS run when accessing the DOM from Rust is generated by the library. The user of the library doesn't have to touch it.

Re: TypeScript 5.0

#322

Earlier quoted context omitted.

> there is currently no sensible way to type a non empty array in Typescript If we remove the "sensible" requirement: type NonEmptyArray = [any, ...any[]]

Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.

Can you map over this and preserve the NonEmptyArray type?

Re: TypeScript 5.0

#323

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.

It’s hard to imagine if you weren’t in the React community at the time, but I feel like most people were pushing Flow at the time and choosing TS was quite controversial. I think it was the combination of Flow being from Facebook, and the “no build step/its just JS with annotations” thing which people made a big deal out of, but I never saw as a big differentiator. I had a hard time convincing a couple of places I wo…

> I think it was the combination of Flow being from Facebook, and the “no build step/its just JS with annotations” thing which people made a big deal out of, but I never saw as a big differentiator.

I put quite some time into evaluating Flow vs Typescript around 2016, and preferred Flow mostly because its type checking was more correct, and its bugs more straightforward. Typescript would happily compile all sorts of incorrect code even with its strictest configs, it was insane.

I eventually found my happy place with Scala.js.

Re: TypeScript 5.0

#324

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.

I get triggered by JSDoc and I really wish I didn’t. To me it’s clearly just more verbose Typescript with less features. I can’t understand the appeal, and most arguments I’ve heard for it can be summed up to “typescript is spooky and I don’t want to learn it so I’ll use this inferior thing instead”, which for my personality, is as hard for me to accept as it would be to suffocate myself by holding my breath.

The only other argument being “no compile step” which is a non-argument in the age of modern bundlers.

Re: TypeScript 5.0

#325
post #183

Earlier quoted context omitted.

Pattern matching was recently added to C#. I can't say quite how well it's been embedded into the language. I always hear great things about F#, ADTs, pattern matching, nice type system and it integrates nicely into the rest of the .NET ecosystem.

F# is great. Simple, small, straightforward, great interop with .NET

Also, the requirement to manually order the compilation units (files) in an XML file to ensure the compiler doesn't get confused.

They had me at features, lost me at manual compilation ordering.

Re: TypeScript 5.0

#326

Earlier quoted context omitted.

Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.

Can you map over this and preserve the NonEmptyArray type?

Do you mean pass in a type?

    type NonEmptyArray = [T, ...T[]];

Re: TypeScript 5.0

#327

Earlier quoted context omitted.

Can you map over this and preserve the NonEmptyArray type?

Do you mean pass in a type? type NonEmptyArray = [T, ...T[]];

I mean if I have a NonEmptyArray say xs, and I then xs.map(x=>2*x), will the result of this expression be a NonEmptyArray ?

Re: TypeScript 5.0

#328

Earlier quoted context omitted.

Does Swift has pattern matching and equivalent of Option/Result enums? I tried it casually but the documentation didn't feel great and things felt like they assumed familiarity with Apple's ecosystem.

Patterns: https://docs.swift.org/swift-book/documentation/the-swift-pr... Optionals: https://docs.swift.org/swift-book/documentation/the-swift-pr... Result: https://developer.apple.com/documentation/swift/result

Swift also supports enumerations with associates values, which is super useful: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Re: TypeScript 5.0

#329
post #158
post #71

Earlier quoted context omitted.

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…

I’ve seen several TS users describe that approach as “branding” (or “flavoring” if it is optional).

Re: TypeScript 5.0

#330

Earlier quoted context omitted.

Does Swift has pattern matching and equivalent of Option/Result enums? I tried it casually but the documentation didn't feel great and things felt like they assumed familiarity with Apple's ecosystem.

Patterns: https://docs.swift.org/swift-book/documentation/the-swift-pr... Optionals: https://docs.swift.org/swift-book/documentation/the-swift-pr... Result: https://developer.apple.com/documentation/swift/result

Thanks for the links - I did the Swift Tour and the language has indeed come a long way since I tried it last time; quite expressive and nice to write in. Hopefully it gains traction in non-Apple circles as well.
Post reply on HN