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).
A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.
But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance.
It probably won't ever happen though.
> It's easy to reimplement typescript in go 1:1 just by looking at the code.
That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.
Can you elaborate why that's a factor? The tools are just binaries in how they're used, the language they're written in is no longer a factor then.
It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.
They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.
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.
the difference is with roads you dont get a lot of good secondary effects, one lane is just like the next. benefits are linear with the cost so they balance out. but with typescript and software in general they can be exponential.
fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.
Most complex, perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate?
(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
> in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust
imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
I'm reading a lot of style / flavor / quality / vibes in your reply, something that will be different between every developer (for the most part); the thing with Go is that there's a lot less of that in the wider ecosystem.
Algorithm W is like undergrad level of sophistication. People who like HM more (and I am one) don't like it because it's "advanced" and to some extent exactly because it isn't. It's sound and fast and infers almost everything. TS seems to have one of those features now, so that's nice.
> most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out)
This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?
The original poster was referring to the golang port of TypeScript which was done almost exclusively for performance reasons. They weren’t just making an unprompted comparison of two type systems.
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.
They picked Go after meaningfully considering Rust (and others). I don't remember all the reasons for it but it was detailed in the original blog post.
There's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads:
> 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.
There just aren't that many spots where the average js dev actually needs to touch a generator.
I don't really see generators ever crossing into mainstream usage in the same way as the other features you've compared them to. Most times... you just don't need them. The other language tools solve the problem in a more widely accessible manner.
In the (very limited & niche) subset of spots you do actually need a generator, they're nice to have, but it's mostly a "library author" tool, and even in that scope it's usage just isn't warranted all that often.
mainly because they messed up on implementation, in two ways. This is of course my opinion.
The first being `.next()` on the returned iterators. If you pass an argument to it, the behavior is funky. The first time it runs, it actually doesn't capture the argument, and then you can capture the argument by assigning `yield` to a variable, and do whatever, but its really clunky from an ergonomic perspective. Which means using it to control side effects is clunky.
The second one how it is not a first class alternative to Promise. Async Generators are not the most ergonomic thing in the world to deal with, as you have the issues above plus you have to await everything. Which I understand why, but because generators can't be used in stead of Promises, you get these clunky use cases for using them.
They're really only useful as a result, for creating custom iterator patterns or for a form of 'infinite stream' returns. Beyond that, they're just not all that great, and it often takes combining a couple generators to really get anything useful out of them.
Thats been my experience, and I've tried to adopt generators extensively a few times in some libraries, where I felt the pattern would have been a good fit but it simply didn't turn out most of the time.
I think writing an effect library yourself is a tough ask, but some of them have gotten really, really good. And they get you things that are simply not possible with promise. Check out Effection if you want a more vanilla javascript syntax, or Effect if you're really into expressing things functionally.
It is a specialised instrument but a useful one: batch processing and query pagination are first class use cases for generators that can really simplify business logic code. Stream processing is another and in fact Node.js streams have had a generator API for several releases now.
Generators peaked in redux- saga and thunk days before we had widespread support for async/await.
You're right, mostly pointless syntax (along with Promise) now that we can await an async function anyway, especially now with for .. of to work with Array methods like .map
But there are still some use cases for it, like with Promise. Like for example, making custom iterators/procedures or a custom delay function (sync) where you want to block execution.
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?
You can see durable execution as a combination of persistent state and queues (simplified example). With regular queues, the state is spread across many places from messages, runtime and external storages where the primary value is the reliability of the message processing and simple error management. Durable brings more advanced error management and end to end reliability with persistent state.
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.
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).
huge congrats to the team!
looking forward to the Rust rewrite ;)