dimitropoulos

nope! never heard of them! (note: I'm the guy that did the Doom in TS types thing) what type-level fun do they bring to the table?

I answered here https://news.ycombinator.com/item?id=48838629

I was referring to the type system in the formal "specification" sense, not the implementation details of the compiler, such as the compiler's runtime (Go, or, in the past, JavaScript/Node). it's too bad there's no specification for TypeScript the way there is for JavaScript and many other things (most?). in that sense, the performance of the type system is uncoupled from the semantics of the type system itself (as the Go port has thoroughly illustrated!).

I mentioned Hindley-Milner because I am under the belief that the HM system (as in OCaml) is, in the same formal/semantic/specification sense, perhaps more advanced. but, as is often with these things, the rubber meets the road on which one of them has been shown to actually run Doom, lol, to which TypeScript is currently the undisputed king.

jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that.

in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types.

[1] https://en.wikipedia.org/wiki/Jevons_paradox

good points, let's get negated types and higher kinded types in there then you've got yourself a deal. maybe regex thrown in too for flavor

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out).

huge congrats to the team!

looking forward to the Rust rewrite ;)

there's also a DeepSeek whitepaper on this technique https://www.seangoedecke.com/text-tokens-as-image-tokens

Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers.

I'm getting so tired of hearing this. I loved the article and it's interesting stuff, but how many more decades until people accept generators as a primitive??

used to hear the same thing about trailing commas, destructuring, classes (instead of iife), and so many more. yet. generators still haven't crossed over the magic barrier for some reason.

it's interesting that in this article you see all three: TypeScript, Typescript, and typescript.

with all the hype around durable execution... what makes it difference from job queuing solutions like BullMQ or Agenda.js that rely on DLQ on top of Redis or Mongo? is it just a DX thing?

wow great example - I'm also baffled by this. is this just not a great example because it seems like it's reinventing the wheel

didn't the latest unreal release have something voxel related? cool to see more voxel stuff happening. we've come a long way since the Euclideon "unlimited detail" days.

the Doom in TypeScript types project wouldn't have been possible without Nick and Helion - I owe Nick a huge thanks! He helped with some of the more obscure parts of the engine and also helped make a super small WAD that is what the game eventually ran in.

Legend.

you're faulting a headline for being precise and accurate. there is no sense in which TypeScript is a runtime. TypeScript is literally a complier (targeting JavaScript, which has runtimes) and nothing more and has always been as such.

Most notably: a very prominent camera (the PYXIS 12K) was announced on Friday for $4,995 USD and on Sunday was changed to $6,595. Almost all other prices saw this 34% increase (but only for the US, all other countries are unaffected).

Thanks for explaining. But I guess I'm still not clear on how the work gets divvied up. Not tryin to be a hater - I'll have to give it a spin - but that part's a bit murky to me still.

thank you for the clarification. you're right. I guess I was just trying to say that it's a spectrum (even if Rust is very very far along the way towards not having any holes). I can't seem to find it but there's some Tony Hoare or maybe Alan Turing quote or something like that about the only 100% correct computer program to ever exist was the first one.

hi! author of the Doom thing, here. while I won't be the one to try, my answer is "absolutely yes, it will make a massive difference". Sub-1-day Doom-first-frame is probably a possibility now, if not much more because actually the thing that was the largest bottleneck for Doom-in-TypeScript-types was serializing the type to a string, which may well be considerably more than 10x faster. Hopefully someone will try some day!

did you contribute to the current TypeScript codebase? (not intended snarky, just curious)

I love Rust, but you can play exactly the same game with Rust: https://github.com/Speykious/cve-rs

well, thanks for explaining. we might just simply disagree here. when I hear "TypeScript" I think of TypeScript, and when I hear "JavaScript" I think of JavaScript. I know what you mean re: casually speaking, but this is a blogpost from the TypeScript team. That context is there, too. I think if the same title were from an AWS release note, I'd totally see what you mean.

yes, and TypeScript is not JavaScript. Objectively, every element of _TypeScript_, strictly speaking, is well known to be separate.

he went into the C# question in more detail this interview: https://youtu.be/10qowKUW82U?t=1154s

he went into more detail about C# in this one: https://youtu.be/10qowKUW82U?t=1154s

look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit? I know what you're getting at but the blogpost itself doesn't imply that JavaScript is 10x faster. I could complain, about your suggested change, that it's really `build and typecheck` time. It's a title. Sometimes they don't have _all_ the context. That's ok.

thank you, to both of you, for so many years of groundbreaking work. you've both been on the project for, what, 11 years now? such legends.

yes, this will definitely vastly increase the Doom fps, haha (I’m the guy that did that project). But I think there’s a lot more to it than that.

tl;dr — Rust would be great for a rewrite, but Go makes way more sense for a port. After the dust settles, I hope people focus on the outcomes, not the language choice.

I was very surprised to see that the TypeScript team didn’t choose Rust, not just because it seemed like an obvious technical choice but because the whole ecosystem is clearly converging on Rust _right now_ and has been for a while. I write Rust for my day job and I absolutely love Rust. TypeScript will always have such a special place in my heart but for years now, when I can use Rust.. I use Rust. But it makes a lot of sense to pick Go.

The key “reading between the lines” from the announcement is that they’re doing a port not a rewrite. That’s a very big difference on a complex project with 100-man-years poured into it.

Places where Go is a better fit than Rust when porting JavaScript:

- Go, like JavaScript and unlike Rust, is garbage collected. The TypeScript compiler relies on garbage collection in multiple places, and there are probably more that do but no one realizes it. It would be dangerous and very risky to attempt to unwind all of that. If it were a Rust rewrite, this problem goes away, but they’re not doing a rewrite.

- Rust is so stupidly hard. I repeat, I love Rust. Love it. But damn. Sometimes it feels like the Rust language actively makes decisions that demolish the DX of the 99.99% use-case if there’s a 0.001% use-case that would be slightly more correct. Go is such a dream compared to Rust in this respect. I know people that more-or-less learned Go in a weekend and are writing it professionally daily. I also know people that have been writing Rust every day professionally for years and say they still feel like noobs. It’s undeniable what a difference this makes on productivity for some teams.

Places where Go is just as good a fit as Rust:

- Go and Rust both have great parallelism/concurrency support. Go supports both shared memory (with explicit synchronization) and message-passing concurrency (via goroutines & channels). In JavaScript, multi-threading requires IPC with WebWorkers, making Go’s concurrency model a smoother fit for porting a JS-heavy codebase that assumes implicit shared state. Rust enforces strict ownership rules that disallows shared state, or we can at least say makes it a lot harder (by design, admittedly).

- Go and Rust both have great tooling. Sure, there are so many Rust JavaScript tools, but esbuild definitively proves that Go tooling can work. Heck, the TypeScript project itself uses esbuild today.

- Go and Rust are both memory safe.

- Go and Rust have lots of “zero (or near zero) cost abstractions” in their language surface. The current TypeScript compiler codebase makes great use of TypeScript enums for bit fiddling and packing boolean flags into a single int32. It sucks to deal with (especially with a Node debugger attached to the TypeScript typechecker). While Go structs are not literally zero cost, they’re going to be SO MUCH nicer than JavaScript objects for a use-case like this that’s so common in the current codebase. I think Rust sorta wins when it comes to plentiful abstractions, but Go has more than enough to make a huge impact.

Places where Rust wins:

- the Rust type system. no contest. In fairness, Go doesn’t try to have a fancy type system. It makes up for a lot of the DX I complained about above. When you get an error that something won’t compile, but only when targeting Windows because Rust understands the difference in file permissions… wow. But clearly, what Go has is good enough.

- so many new tools (basically, all of them that are not also in JS) are being done in Rust now. The alignment on this would have been cool. But hey, maybe this will force the bindings to be high-quality which benefits lots of other languages too (Zig type emitter, anyone?!).

By this time next week when the shock wears off, I just really hope what people focus on is that our TypeScript type checking is about to get 10 times faster. That’s such a big deal. I can’t even put it into words. I hope the TypeScript team is ready to be bombarded by people trying to use this TODAY despite them saying it’s just a preview, because there are some companies that are absolutely desperate to improve their editor perf and un-bottleneck their CI. I hope people recognize what a big move this is by the TypeScript team to set the project up for success for the next dozen years. Fully ejecting from being a self-hosted language is a BIG and unprecedented move!

thanks! actually the "why" video is going to talk at some length about my woodworking business, so you might enjoy that part! best of luck to you!

thanks!

hi! author here! selfishly, it'd be really useful to me if you could take a moment to elaborate on your thinking here. it's not an altogether-too-too-uncommon viewpoint and I'd like to understand it if you have a chance.