TypeScript 7
devblogs.microsoft.com
devblogs.microsoft.com
Codebase | TypeScript 6 | TypeScript 7 | Speedup
------------|--------------|--------------|--------
vscode | 125.7s | 10.6s | 11.9x
sentry | 139.8s | 15.7s | 8.9x
bluesky | 24.3s | 2.8s | 8.7x
playwright | 12.8s | 1.47s | 8.7x
tldraw | 11.2s | 1.46s | 7.7x
Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?
Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way.
Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
EDIT: Oh, look, blog post on the front page now.
https://bun.com/blog/bun-in-rust
> Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now.
So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and slated to be the production release soon.
A nice collection of heap-use-after-free crash, use-after-free crash, crash and out-of-bounds read, memory leak, double-free crash, race condition crash.
And I'm not sure how you're responding to my comment. The parent said "this is a marketing stunt" derogatorily, as if it's slop that doesn't work. This is already the canary build, it's more stable than the current stable, and is actively in production products in wide use.
The parent is objectively wrong, whether or not I personally use Bun.
Yes, but that doesn't mean it wasn't also "helped" along by AI.
See:
1. https://github.com/microsoft/typescript-go/pull/1387
2. https://github.com/microsoft/typescript-go/pull/2978
3. https://github.com/microsoft/typescript-go/pull/1138
4. etc...
Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.
---
The initial port was automated, then devs got in there, then LLMs got in there.
1. The change isn't made by a human.
2. The change wasn't fully reviewed by humans or machines. It's not currently possible for a machine to review the whole thing as one.
3. It's a full rewrite. This isn't a ten thousand line change, it's multiple orders of magnitude more than that.
You're literally making the argument that all risk of any size from any change of any size is equivalent, so just don't worry about it. If you relied on this software before, good luck convincing yourself it's fine to rely on this software now: it's literally not the same software anymore.
My position is more nuanced. A) what does the test coverage look like B) how is the deployment managed.
I suspect B is going to be my biggest issue - normally you’d deploy this slowly over time to monitor problems and whatnot. But ultimately the real test is seeing how it actually performs in the wild and kinds of problems people report. But you can always keep using the zig version if you wanted. So ultimately it’s a lot of consternation over a nothing burger. You can laugh at them if they screw up the release, but it’s a bold attempt at trying something legit. It took Microsoft 2 years of many engineer hours migrating typescript to Go. If it takes significantly less calendar time and human time, you could reasonably even evaluate what a Rust based typescript looks like vs Go if you wanted to for an order of magnitude cheaper.
esbuild doesn't rely on TypeScript at all, so there's no issue there.
With tsdown on the other hand, it depends on if you use --isolatedDeclarations. If not, you can install TypeScript 6 side-by-side (instructions for this are on the blog)
> It’s worth calling out that workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7. This is mainly because TypeScript 7 does not yet expose a stable programmatic API, and so tools (such as Volar) which embed TypeScript into their own compilers and language services can only currently rely on TypeScript 6.0. We expect this to be a point-in-time issue, as we are committed to providing a solution here. We will be actively working with the maintainers of these projects to ensure TypeScript 7 supports these workflows.
I love TypeScript, if nothing else for how it's been able to popularize types.
That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.
Static vs dynamic typing is no less ubiquitous in online forums over the decades than tabs vs spaces and vim vs emacs.
e.g. Gradual typing was since added to PHP and Python which ended some debate like how linting tools shut down a lot of whitespace debates.
In the early days they would often say things like "but we have prop types, why use TypeScript", "why not use JSDoc" (this made no sense at the time), or "it's an exercise in needless complexity". It was really tough to sell them on TypeScript for years.
I think there are developers who are very goal-oriented with a narrow perspective on getting from point A to point B, and their understanding of the process isn't particularly holistic, rigorous, or geared towards external or knock-on factors like maintainability, performance, bugs, etc. They deal with it when circumstances force them to, and no sooner. Defining types is a complete waste of time to someone like that.
These people thrive where teams are primarily expected to just ship things, and in my experience they often hate needing to think about things like types, tests, or code quality beyond running a linter.
So, they're serious people in one school of thought. They contribute meaningfully to projects. I think they're a large constituent of the new class of vibe coders who laugh at you if you look at the code. That's fine, they're doing their thing, and there are more than a few ways to get programs into people's hands. That way just isn't the way I like to.
Obviously "production quality" varies greatly from shop to shop, but I think there's more legitimacy to the idea than you're giving it.
This is totally fine sometimes though, because like you say, there are shops where this type of execution is suitable. It's why vibe coding is actually okay in many cases; it's not a lot different from what it replaces in these cases. There are a lot of situations where this is the bar, it produces enough utility an value, and that's great.
Personally - I also think people really underestimate just how much the tooling around types has improved over the last 20 years.
If I'm having to try to look up the difference between iBrowserInterface6 and iBrowserInterface5 and iBrowserInterface4... (and yes - shit like this really did exist: https://learn.microsoft.com/en-us/windows/win32/api/shdeprec...)
And I have no tooling for autocomplete, and the docs are shoddy, and google is just coming on the scene...
People understandable want to throw their computer out the window.
Types are great. Some forms of them were not.
I just don't think this is true.
Frankly - it's hard to argue this at all (even today) given that JS is the dominate language on the planet, and it lacks types... as does python, which had a reputation for decades as THE language to use to teach new folks to code. Or take PHP which dominated server development for a LOOONG time: also lacks types. Ruby on Rails has a wonderful reputation as the "get shit done" framework: no types.
Types are good for modern software companies, where code size has ballooned up very high (common to work on a codebase with hundreds of thousands of lines) or teams are large (50+ developers) and terrible if you just want to hammer out something that works as a solo dev.
Do I like types today? Sure - the tooling is solid, and I work on large codebases with large teams.
Did I like types as a solo dev at 3 person startup? no.
I am very perplexed by this. I am going through Neetcode's DSA course where he explains what RAM and arrays are, but then he goes on to say something like "but since we are going to use Python, none of this applies." Personally, I learned the most about how software really works from reading The Rust Programming Language. It not only teaches you how to program in Rust, but also how memory works, what a string really is, etc.
At a startup you can choose even fancier languages, since nobody is stopping you!
When companies started making enterprise-scale JS applications they had to solve for the type story because it is unmaintainable otherwise. TS is the winner in a long line of iterating on that problem.
And before Java finally settled on what we have today, we had 3rd-party libraries like jodatime that tried to fix it.
I guess it’s in a good state today, but it took a LocalDateTime.MAX to get there. I mean an Instant.MAX. No, I mean an OffsetDateTime.MAX. No, I mean new Date(Long.MAX_VALUE). Oh wait I meant new Timestamp(Long.MAX_VALUE). No, I mean LocalTime.MAX.
I’ll stop now, but i could go on.
I still feel this way about the state of the art. I want solid type support in my language ... but I do not feel TypeScript is the best possible implementation at all, and for many situations I feel implicitly typed (but still using all of VS Code's type features) Javascript is actually better than using TypeScript.
I eagerly await the day when someone actually gets a JS typing tool right and I prefer using it over raw Javascript.
WinRT for all its pain points, is still COM, only with a different set of base interfaces, and using .NET metadata instead of classical COM type libraries.
was amusing to come back hours later and find out whether this comment ended up more upvoted or more downvoted, it was oscillating all day...
So, not sure that counts as "serious" in your estimation, but I would definitely argue that dynamically typed languages are superior for a large class of problems.
Also, just a tip: it's usually better to be less sure of yourself, and seek to understand other's reasoning. It'll get you a lot farther than trying to convince everyone of how right you are.
If you're not sure why an experienced developer would hold an opinion different than yours, why not just ask?
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs. But a codebase in production is unlikely to have much type related bugs...
I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.
The concept of them being more than compiler bookkeeping, but as propositions about program behavior and invariant encoding is more than 50 years old at this point.
What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing.
(Just checked sorbet landing page, looks like it's mainly/only for fn signatures?)
A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.
Me when my manager asks to complete the JIRA ticket.
There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.
> where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.
hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?
I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all.
Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior.
In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.
* Maybe. Not quite sure about "weak" for this one, but I think it makes sense because you can just lie to typescript and then after compilation it just runs as javascript.
Like I said, if you're going to talk about automatic type conversion, then calling it "automatic type conversion" is probably the simplest option - strong vs weak typing doesn't really need to come into it. Then you avoid any definitional confusion.
But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime.
Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like".
It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.
Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them.
Example:
const dogs: Dog[] = []
// A sound type system would error here,
// but there's too many useful cases where you want to do this
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() // runtime TypeError here class Animal { }
class Dog extends Animal{
bark(){return 1}
}
class Cat extends Animal{
bark(){return 1}
}
const dogs: Dog[] = []
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() <<<<< "Property 'bark' does not exist on type 'Animal'."I didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way.
It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;)
For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough to figure out what I mean, in the absence of ambiguity. Like imagine this C code:
int main() {
int i = 23;
auto j = i;
printf("i = %d, j = %d\n", i, j);
}
fn foo1() -> i8 {
23
}
fn foo2() -> String {
"foo2".into()
}
fn main() {
let f1 = foo1();
let f2 = foo2();
let f3 = f1 + f2;
println!("Hello, world!");
}
I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.
FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.
In C++ one can declare a completely typeless lambda:
auto callsAdd = [](auto x, auto y) { return x + y; }
I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.
You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.
So:
i = 23 # Create an int(23) object and store its address in i
i = "foo" # Create a str("foo") object and store its address in i
> Python's strong typing mostly boils down to some operator rejecting mixed types.
Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.
> It's also pragmatic...
So it's almost like Javascript. That something is not a source of bugs, is not proof of strong typing. Python uses type information in some cases, that's it. E.g., it's trivial to load some record or file of the wrong type, and only find out much later. That's a real source of very unpleasant bugs.
But by most people definitions, Python certainly is NOT strongly typed.
My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs.
It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.
for the record - I agree completely.
(glad people are over the unicode thing!)
the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.
I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.
Get the f*ck outta here.
Come on, that was very clearly what he was talking about. No need to be this pedantic.
I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about.
Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as propositions about program behavior like in ML, which highly influenced modern type systems, including TypeScript, albeit Ocaml, F# and the Rust type system belong to the ML family.
> if nothing else for how it's been able to popularize types.
This is such an odd, javascript dev take.
Even before JS became the language for everything, there was a good chunk of time - maybe between 2005 and 2015? - when Python and Ruby were dominant in this environment, and this dismissive attitude towards static typechecking was similarly dominant.
Of course in the enterprise space everyone was using Java, and in the systems space or game dev space everyone was using C++. But those worlds get a lot less airtime here.
Plus everyone on HN is a good little pg disciple, and Lisp is dynamically typed. If the One True Language doesn't need static typechecking (though SBCL offers some very helpful heuristics) surely it's not worth it. Right? Right?
"Lisp" isn't a single language. Arguably the language people speak about when they say Lisp without qualifier, ANSI CL, allows conforming implementations (e.g. SBCL) to offer gradual typing, not just heuristics.
Ish.
SBCL aggressively infers types wherever possible. It can do dynamic typing with tags of course. You can also write it with 100% static types.
Dynamic typing isn't a defining feature of Lisp style languages (even GC isn't necessary). Some historic Lisps and modern ones are 100% statically typed.
Um, isn't it? Don't all Lisp variants have it? IIRC McCarthy's LISP just ran out of memory until the GC was written.
No. There's been GC-less Lisp's over the years, here's a good paper on one: https://dl.acm.org/doi/10.1145/142137.142162
There was also pre-Scheme, GOAL, nowadays there's Carp and Dale. Zeta Lisp (and now SBCL) had/have arenas and you can manually allocate, etc...
> McCarthy's LISP
McCarthy also envisioned it having M-expressions.
edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.
P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.
Once you see what good application of types look like, is far better sell!
Functional programmers keep hyping up ADTs like this but the normie programmer doesn't care about ADTs or immutability. What really brought back static types was Golang & typescript, both have local variable type inference, good IDE support & other tooling, and (at least superficially) lighter weight syntax than Java. Normies don't care about algebraic types, pattern matching, immutability, referencial trasparency, type classes. What matters is libraries and tooling.
Why certain approaches didn't catch on until recently, or ever, is an interesting thing to think about but "we didn't know how" is not the story here.
That's the difference between "having a typing error" and "having an error due to typing".
well kinda
Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
"x = " and there are only two variables in the scope with the same type so IDE will present them to you in a drop down and you can already think about the next line.
Fast forward to ~2015 when I'm working on Angular project. The whole idea feels like a caricature Chinese whispers of an OOP framework. Each component is divided into three files, all of them have to identify themselves using a magic string, and that string has to be manually entered into each file.
There are couple of type systems, like the one from Facebook, but no one is using them. And everyone claims that OOP and types are the thing of the past.
Part of that corelates to a joke I was making back in 2013, soon after Apple killed Flash and everyone started doing JS everywhere. Major companies where posting job offers for senior javascript devs asking for 5-7 years of experience. But someone who was doing JS for 7 years in 2012 has all his career focused around gluing together jquery plugins.
Anyway, I'm as well glad that we finally did a full circle and finally have some sanity in the industry...
> Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
> Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
I think you’re off by at least 6-7 years. Visual Studio had autocomplete since at least version 6. And yes it was magical the first time you experienced it.
Ever wondered why, even on modern websites, css is riddled with repeated statements with this weird "moz-" prefixes?
In 2006 when working at Wikia I wrote a tiny lib for deep linking.
The lib started at 25 lines with naive implementation of the documentation. Two weeks later when I had all browsers on all operating systems mapped out it was close to 1,000 lines.
I've spent half of my coding time working with Flash, and the monopoly was great. You could make a layout, write a code and have absolute certainty that the outcome will look and feel exactly the same regardless if you ran it on desktop, in the browser - any browser, mobile or kiosk.
Few years later I did UI for The Witcher and Dead Island and with that you can add xbox and playstation to the list.
Last time I did some web programming was 3 years ago, but it was still a far cry from that experience.
My father took me to that conference so that would be closer to 2000 or 2001.
Fun fact, around that time I attended 3 "microsoft summit" - that was the name of the event - and every time the absolute banger, booked out months before the event, was a workshop with a guy who specialized in optimizing windows licensing for enterprise.
That was still the time when MS charged per CPU on servers, and the guy used to give couple seemingly basic scenarios and asking crowd how would they deal with licenses. Every time his version was 3-4x cheaper than what you would think of.
It's more common on consultancy than product companies.
Consultancy is getting paid for doing things. Product company is getting paid for getting things done.
I don't enjoy writing it, but I don't mind to maintain it, all apps have a predictable architecture.
Performance wise it's also extremely good, between stream based rendering and deferred rendering you can trivially ship lean and fast code.
It's a great fit for large parts of the industry defaulting to react which is notoriously difficult to tame when performance matters.
My read is that people were never really against types: they were against type systems that got in the way. Older ones often weren't expressive enough, so you ended up writing verbose patterns just to appease the compiler.
That's why dynamic languages gave startups a sizable velocity edge for a while. Modern type systems (with optionals, unions/sum types, inference, etc.) are completely different.
To paraphrase a comment I once read here on Hacker News: I'll take static typing with sum types over dynamic typing, but I'll take dynamic typing over static typing without sum types...
The discussions and articles online seemed to infer that, but that's uh. media bias? Hype? Things written about and things you read online are not the full story, is all.
it is not an either or.
Yes, it's a skill issue, but oh dear the amount of developers who have that issue.
At worst, TS can only really be as bad as JS, no?
”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.
Even without TS, I'd be using zod (or a similar library). I haven't had any issues with zod's bundle size, and I don't see a good reason to write custom encoders/decoders everywhere.
huge congrats to the team!
looking forward to the Rust rewrite ;)
(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
Go is great because it's fast to code.It's easy to reimplement typescript in go 1:1 just by looking at the code.
Rust on the other hand would take a lot longer to develop.
Maybe rust is 20% faster than go but overall the increase from typescript with go is good enough.
Maybe rust would yield a 14 times speedup over the 11 times in vscode but go is already good enough to make a huge difference.
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.
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.
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.
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.
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.
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)?
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.
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.
The blog post: https://devblogs.microsoft.com/typescript/typescript-native-...
Why Go? https://github.com/microsoft/typescript-go/discussions/411
Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410
Honest question, what do you mean by this?
[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.
And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.
I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.
WASM
All my side projects for the last year+ have used full stack Rust.
My project is a webapp, but I have node types in my ide tooling because of vite.config.ts, and playwright and unit tests. If I add a node api to a react component, tsc won't complain.
Current method to isolate dom lib from node lib requires project reference spaghetti, numerous tsconfig.json and tsbuildinfo output files, and avoiding emitting types with project references is cumbersome.
I prefer nx for single applications and move shared code to "libraries" (I use non-buildable libs). It's pretty sweet for larger projects.
It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.
I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds.
Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…
1. The default settings aren’t well optimized. So the pattern a lot of people fall into is: start a project and everything’s fast, then add more code and dependencies and everything gets super slow. Then you Google how to fix it, change some compile settings and restructure your project and it speeds up again. Rust requires knowledge and effort to keep compile times reasonable - it’s not set up that way by default.
2. Rust Analyzer / cargo check is inefficient and throws a lot of data away each time instead of caching it. So in a larger project you’re waiting on it to catch up. Waiting on Rust Analyzer to check my code is easily the largest amount of time wasted, more so than actually compiling it.
But it should be said that this is being worked on: https://rust-lang.github.io/rust-project-goals/2025h2/relink...
Microsoft: Take that, Joel!
;)
---
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Even for front end code destined for the browser I rely on Node's type stripping.
I have a longer blog post or audio to post. but in short - the javascript/typescript ecosystem is like working with wood.
you can have your cheap, laminate cardboard wood - Ikea type - the code equivalent will be vibe coded apps that are not original.
then on the high end - you can have your crafted furniture | wooden skyscrapers - that use custom joinery & lamination techniques using young lumber to make to make beams that are fireproof. you can also have high end stuff in the javascript/typescript ecosystem that uses A.I as one uses powerful machine tools but with crafting in mind.
for those that dare to make or dare to do - embrace the typescript|javascript ecosystem.
As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?
This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it.
I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
ts-node cannot be used with typescript@7.
although node@24 can directly run typescript file, but stripe the types, without type-checking, also it require changing the import path with .ts, and it doesn't support import .tsx files.
I've been thinking about this since 2022 and haven't really gotten further than "Hmm, I would like this".
I'm aware that tooling catches most stuff, but being able to shift this even more to the left (compile time) would be great.
I'm just very used to Rust, where my hand is being held
It does need a compiler though, unlike TS where an interpreter can just strip / ignore type annotations. But IMO, a compile step is worth it if you get type assurances in return.
Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts
It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.
So I'm interested on what exactly has been sped up here. I can see compile times have been, but is that it? I suppose the runtime itself was always native code, and already very fast.
A faster type checker will help with performance problems in text editors since type info is needed for a lot of queries.
thanks DanRosenwasser and team for building such an awesome tool for so many years!
Thanks for the link.
And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...
- LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build
which muddies the water a bit, but I'm sure we can get it working
I am still of the opinion that well organized and named JS is all that anyone needs and typescript only exists for fresh graduates and fleeing OOP devs.
edit: also the downvote button HN is not for disagreeing with comments or unpopular opinions.
You probably didn't work on any medium or large codebase and didn't have to do a refactor.
> it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape
What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
> What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and hinting support. The typescript creation team was literally led by the guy who made C#.
That's not the reason for my comment. I truly don't understand how after so many years someone "isn't sold" on TypeScript. Sure, you don't have to use it if you don't want to, but if don't see how it's truly essential in current JS development, I don't know what else to assume, other than OP doesn't have enough experience.
> it was created by microsoft
It was created at Microsft, but it was crated by Anders Hejlsberg who, I'm pretty sure, didn't want to just "create a safehaven to C# and java devs", he was actually solving real problems with JS development, completely orthogonal. You can argue that TS's first syntax was very C/C# inspired, and that Anders also created C#, but that's not what OP meant (or at least how it read).
People have been successfully writing assembly, your argument is useless.
And yet you follow this up by making assumptions about the motivations behind TS. Anders has mentioned that TS was purely motivated by internal MS teams struggling with huge JS codebases, nothing to do with C# but clearly his work on other languages would have influenced how he approached designing the language.
Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically).
I personally don't have a need for TS which introduces an extra build step, extra ritual when defining functions, and no performance benefit over vanilla JS. If I want stricter coding pattern with performance benefits I will use C/C++ for the job instead.
TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.
A clean django project is probably 3-4x less code than the equivalent TS based service.
It made me consider dropping strict mode and defaulting to js for most simple things.
I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers.
(This would drive me absolutely insane, but my agents get over it pretty quickly!)
Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-d...
simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs.
PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).