Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun).
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?
pjmlp 26 seconds ago [-]
The Typescript team is also using AI, even if not to the crazy Bun level.
DanRosenwasser 8 hours ago [-]
> How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase?
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)
paulddraper 4 hours ago [-]
"How does this affect downstream tools"
> 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.
hackerbrother 9 hours ago [-]
Do you think Bun's migration was irresponsible?
ricardobeat 9 hours ago [-]
Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear.
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.
spartanatreyu 6 hours ago [-]
> this TS migration started long before AI was able to help
Yes, but that doesn't mean it wasn't also "helped" along by AI.
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.
docmars 8 hours ago [-]
Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place.
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.
golergka 3 hours ago [-]
Marketing could of course be one of the main motivations, but it's not a "stunt". More like a marketing achievement, I guess? Stunt implies smoke and mirrors, and bun rewrite is quite real.
Tadpole9181 7 hours ago [-]
Not sure I understand. Bun's changes are merged on the dev branch and available for use, no?
> 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.
NamlchakKhandro 4 hours ago [-]
To think it wasn't a marketing stunt is incredibly naive of you or you're intentionally trying to mislead people
jibal 4 hours ago [-]
Your correspondents are arguing in bad faith and out of ignorance.
mindwok 9 hours ago [-]
I don't think irresponsible is the right word, but it has drastically reduced Bun's appeal. All the tools we use have a brand to them, and Bun basically changed their brand overnight to "reckless" in my eyes.
jitl 5 hours ago [-]
bun has never been fit for production, at least not for load bearing business apps. it’s been haunted by segfault bug reports since the early days, and i personally hit at least one a week when im doing lots of bun stuff. im excited for bun with less segfaults
brandensilva 1 hours ago [-]
So reckless but needed.
bastawhiz 9 hours ago [-]
It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.
jitl 5 hours ago [-]
yeah but, the existing code was also full of bugs, so isn’t it all a wash in the end?
bastawhiz 4 hours ago [-]
The initial state has no bearing on whether the process was responsible or not. That's measuring along a different axis. If the bun rewrite lands and it breaks someone's app, that's bad no matter whether there's more or fewer bugs in the final state. The important metric in a rewrite of software that's used in production is stability.
it's impossible to say, as v1.4 is in development and there has been no migration
2 hours ago [-]
adamddev1 12 hours ago [-]
Remember when people would argue about how types weren't worth the effort?
I love TypeScript, if nothing else for how it's been able to popularize types.
kstrauser 12 hours ago [-]
I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conversations over the years 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.
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.
_flux 10 hours ago [-]
There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression.
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.
jt2190 10 hours ago [-]
> Strongly typed and weakly typed do not seem to have good definitions.
Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
dtech 10 hours ago [-]
There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed.
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
arcfour 10 hours ago [-]
Okay, so I'm not crazy for thinking that declaring an empty, typed array as `const` and then writing/pushing to it is confusing/feels wrong.
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 ;)
have_faith 8 hours ago [-]
`const` in JS doesn't refer to the array being immutable, only that the variable referencing it stays the same (it can't be reassigned), so this is normal in JS.
rbits 7 hours ago [-]
I don't think that's what the comment you're replying to is saying
bennettpompi1 10 hours ago [-]
I may be missing something, but your example doesn't typecheck?
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'."
anematode 9 hours ago [-]
Should be `dogs[0].bark()`
jt2190 10 hours ago [-]
I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.
9 hours ago [-]
kstrauser 10 hours ago [-]
That's fair, and I don't claim that I have the canonically correct answers. My broader claim is that I don't think I've ever heard someone say ugh, I despise that my bucket of bytes has an associated type! The real discussions weren't against types, but against various type disciplines.
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);
}
There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can:
fn foo1() -> i8 {
23
}
fn foo2() -> String {
"foo2".into()
}
fn main() {
let f1 = foo1();
let f2 = foo2();
let f3 = f1 + f2;
println!("Hello, world!");
}
Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.
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.
delta_p_delta_x 9 hours ago [-]
This is called automatic type inference, and it is a big feature of functional programming languages, many of which are very strongly typed. Also, for the record, C++ gained type inference about a decade and a half ago.
In C++ one can declare a completely typeless lambda:
auto callsAdd = [](auto x, auto y) { return x + y; }
And the programmer need never specify what x and y are, as long as there exists a reachable declaration of operator+ that has two arguments that accepts whatever x and y resolve to, at instantiation time (which is compile time).
ameliaquining 6 hours ago [-]
I think it's pretty widely recognized these days that type inference for local variables is a good idea. Most major languages that didn't previously have it have since added it.
tgv 10 hours ago [-]
Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.
kstrauser 10 hours ago [-]
Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator.
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
i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't.
> 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.
munchbunny 5 hours ago [-]
> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.
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.
5 hours ago [-]
tyingq 8 hours ago [-]
Last I tried, there's still often (not always) fighting with typing, mypy, pyright because of the dynamic nature you mention. I think the complaints about it are sometimes misinterpreted as "disliking types".
baq 9 hours ago [-]
haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5.
for the record - I agree completely.
(glad people are over the unicode thing!)
nsonha 6 hours ago [-]
> static, explicit typing
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.
fatata123 6 hours ago [-]
[dead]
librasteve 8 hours ago [-]
[flagged]
skybrian 10 hours ago [-]
[dead]
sysguest 12 hours ago [-]
> I don't recall anyone disliking types
> 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?
delta_p_delta_x 11 hours ago [-]
That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.
MrJohz 11 hours ago [-]
That's also true of Python, though, which is traditionally considered a strongly typed language.
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.
jbritton 7 hours ago [-]
My understanding of weak typing is about allowing automatic type conversion. “3” + 1 === “31”, 1 + “3” === 4. Strong typing doesn’t auto convert.
Izkata 5 hours ago [-]
Pretty much. There's probably better examples but using some of what's come up here so far: python is strong+dynamic, javascript is weak+dynamic, typescript is weak+static*, java is strong+static.
* 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.
Xixi 3 hours ago [-]
There's been a pendulum swing of sort during my career: static languages like C++/Java, then dynamic ones like Python/Ruby/JavaScript, and now back toward typed languages like TypeScript/Rust/Swift.
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...
zeroq 5 hours ago [-]
In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).
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...
koolba 4 hours ago [-]
> In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).
> 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.
nicoburns 10 hours ago [-]
Type systems just used to be bad. Anything that forces you to use a class hierarchy to represent an "OR" type (sum types) is painful to work with. Modern languages like TypeScript / Rust / Swift / Kotlin that have sum types are dramatically much nicer.
giraffe_lady 5 hours ago [-]
Algorithm W is 40 years old and HM has vastly better ergonomics than TS's types.
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.
dboreham 3 hours ago [-]
C also has sum types.
keyle 3 hours ago [-]
No if you're referring to unions and an enum, it isn't sum types.
JoeyJoJoJr 9 hours ago [-]
I have personally had three conversations (2 online, 1 in person) where the other person has said, almost verbatim, “I have never had a typing error in JavaScript”. Two of these people were people whose work I respected, so it could not understand how they could possibly hold that position.
chuckadams 4 hours ago [-]
"I have never had a typing error in Javascript" — [Object object]
antod 6 hours ago [-]
It isn't wrong exactly. JS is famous for generally just trying to do something semi random instead of giving you a typing error.
That's the difference between "having a typing error" and "having an error due to typing".
well kinda
mamcx 10 hours ago [-]
Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!
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!
lurkercodemnky 4 hours ago [-]
> algebraic + pattern matching
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.
adamddev1 7 hours ago [-]
Now I'm just waiting for DependentTypeScript :-)
dboreham 3 hours ago [-]
You need to meet some people who argue that types are positively bad!
bbg2401 11 hours ago [-]
> Remember when people would argue about how types weren't worth the effort?
> if nothing else for how it's been able to popularize types.
This is such an odd, javascript dev take.
wk_end 10 hours ago [-]
It's maybe a bit of a startup-world, HN-blinkered assessment...but that's where we're talking, isn't it?
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?
dismalaf 10 hours ago [-]
> Lisp is dynamically typed.
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.
trealira 57 minutes ago [-]
> even GC isn't necessary
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.
BoingBoomTschak 10 hours ago [-]
> Lisp is dynamically typed
"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.
adamddev1 11 hours ago [-]
I'm a Haskell and FP nerd as well. I just meant the argument and the popularity inside the JS/TS world, which is fairly significant. I think the world is a better place because of the widespread adoption of TS over JS.
chem83 12 hours ago [-]
dhh is still not very fond of it. To each their own.
> TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks!
That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
hvb2 11 hours ago [-]
Types are a safeguard, they rule out certain errors. So using them is mostly for maintainability, and especially in large codebases and teams that becomes a thing.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
egorfine 11 hours ago [-]
> Types are a safeguard, they rule out certain errors
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.
Xixi 3 hours ago [-]
Static types are not _that_ useful to catch bugs, if only because type related bugs tend to surface very quickly, especially in strongly typed language like Python. So a good CI suite is usually enough to catch them, but you do need good coverage. Even if they make it to prod, they won't survive long...
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...
zoul 2 hours ago [-]
Catching bugs in CI is orders of magnitude slower and more expensive than catching them as type errors while writing the code.
overfeed 10 hours ago [-]
eons ago, I migrated a frontend to Typescript and caught a lot of type-related bugs[1]. It was a 5kLoC, fast-moving productized prototype written by a team of 5. I won't ever do dynamic-typed plain Javascript in a team ever again, type-checker is superior to human code-reviews when it comes to catching potential bugs. Then again I prefer codebase stability of clever code or "expressiveness"
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.
zoul 2 hours ago [-]
Static type checking greatly affects code design. That’s why converting from JS to TS doesn’t give you full benefits of the type system – the code doesn’t lean into types to model invariants.
lurkercodemnky 4 hours ago [-]
> so little joy to my development experience, and quite frequently considerable grief
Me when my manager asks to complete the JIRA ticket.
dymk 10 hours ago [-]
I'm a Ruby enthusiast - Sorbet is one of the best things since sliced bread to happen to the ecosystem. matz is pushing hard on static typing as part of the standard Ruby ecosystem as well.
spect88 1 hours ago [-]
Matz hates (inline) type annotations and said many times that they're not coming to Ruby. IIUC he only allowed RBS (type annotations in separate files) due to community pressure.
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.
matltc 9 hours ago [-]
Really? Matt is pushing for it now? Dang. Might try Sorbet out.
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?)
12 hours ago [-]
aaronvg 11 hours ago [-]
these painpoints seem moot in a world where AI agents are writing all the code.
recursive 9 hours ago [-]
Type declarations can help an LLM in the same way they help people.
overfeed 10 hours ago [-]
That world will never be. Humans will always be writing some code, at least for as long as I live and breathe.
IshKebab 8 hours ago [-]
I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time.
austinthetaco 11 hours ago [-]
I still do argue that for JS. I have yet to see it worth the effort other than making things feel comfortable for former OOP devs coming from other languages.
edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.
vlian2088 8 hours ago [-]
people didn't argue against types, people argued against putting lipstick on a pig.
ajkjk 12 hours ago [-]
I don't think ... serious people... argued that.
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.
steve_adams_86 12 hours ago [-]
I worked with people who would consider themselves serious, and are still in the industry and doing fine. A few have certainly gone on to be more prominent and get paid a lot more than I am—not that it's a perfect measure of seriousness.
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.
hungryhobbit 8 hours ago [-]
Serious developers can make a serious argument that you can get quality production-level code with other ways besides explicit enforced type systems (eg. that if you have good enough test coverage such explicit type systems are a redundant waste of time).
Obviously "production quality" varies greatly from shop to shop, but I think there's more legitimacy to the idea than you're giving it.
steve_adams_86 7 hours ago [-]
I didn't mean to paint with such a broad stroke, there. I've worked with people who are capable of writing exceptional software without type systems or other abstractions. I'm not that smart, though. I need a lot of guard rails to keep myself from doing stupid things. I was speaking more generally about people who didn't produce exceptional code yet still weren't open to means of improving their work if it meant having to open their minds to new ways of working.
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.
horsawlarway 12 hours ago [-]
Look at some of the typing present in MS COM back in the IE5/6 days and we can discuss more. I can honestly tell you - I'll take untyped languages any day of the week over that clusterfuck.
Personally - I also think people really underestimate just how much the tooling around types has improved over the last 20 years.
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.
ajkjk 12 hours ago [-]
completely agree. but I felt like even then it was clear that types were a good idea and the implementations were not. For instance I started programming on Java 4 or 5 and the types were pretty bad---but still it was obviously the right way to go compared to JS or, god forbid, shell.
hungryhobbit 8 hours ago [-]
"even then it was clear that types were a good idea and the implementations were not"
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.
horsawlarway 12 hours ago [-]
> but still it was obviously the right way to go compared to JS or, god forbid, shell.
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.
mckee_plus_plus 8 hours ago [-]
When I start a hobby project without types, and then get mental fatigue when returning to a shelved codebase and add ts, I find lots of bugs just by adding types.
jazzypants 9 hours ago [-]
It's still useful for things like onboarding the fourth person to your start-up. Good types get you half the way to good documentation.
dprkh 11 hours ago [-]
> as does python, which had a reputation for decades as THE language to use to teach new folks to code
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.
ameliaquining 7 hours ago [-]
Learning the basics of programming is hard enough without also having to learn all those low-level details at the same time.
esafak 9 hours ago [-]
Those languages dominated because they were simple. Then they grew, and their users grew up, and realized that worse is better.
At a startup you can choose even fancier languages, since nobody is stopping you!
TedDoesntTalk 12 hours ago [-]
Java has a lesson of what can go wrong with types, just as parent says. That example is dates and times. So many types…
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.
ameliaquining 7 hours ago [-]
How would dynamic typing have helped with this? Presumably all those different classes would still exist and create fragmentation and compatibility problems; they'd just surface at runtime instead of compile time.
nh23423fefe 10 hours ago [-]
This isn't a good example at all. Those interfaces are subtypes.
ChadNauseam 12 hours ago [-]
It's easy to say that now, but it used to be that all mainstream typed languages had absolutely terrible type systems that got in your way as much as they helped
steve_adams_86 12 hours ago [-]
Absolutely, TypeScript is remarkably expressive in my opinion. The inference and option to bail out with `any` is nice for some teams in some cases, too. They did an excellent job of making it accessible.
mrkeen 11 hours ago [-]
They're still right here in sibling comments
ajkjk 4 hours ago [-]
guess so. I still don't think their position is serious, but, that's just me.
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...
hombre_fatal 12 hours ago [-]
> I don't think ... serious people... argued that.
Static vs dynamic typing is no less ubiquitous in online forums over the decades than tabs vs spaces and vim vs emacs.
ajkjk 12 hours ago [-]
I feel like I see all of these debates far less than I used to? Well I don't see anyone arguing about vim and emacs anymore at all, and spaces have mostly won over tabs, and static typing has mostly won over dynamic, with the holdouts being comparative novices and people who program in less modern environments, like in academia and at smaller companies.
asa400 11 hours ago [-]
Are the banks and trading firms that use e.g. Clojure/Elixir/Erlang/Python "comparative novices" or "less modern", whatever that means? These are some of the most sophisticated shops I've ever seen, doing some serious software engineering. I like static types as much as the next person and have written probably more Rust and Scala than anything else, but this seems maybe a bit of a gross generalization.
hombre_fatal 12 hours ago [-]
Yeah, we are definitely past the hey day of these debates, though you can still find them.
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.
alserio 11 hours ago [-]
Spaces over tabs? Since when?
ajkjk 11 hours ago [-]
i could be wrong, but it was enforced as the default at several places I worked, and most editors now have the option of the tab key inserting spaces to bridge the gap. (I don't care about the actual debate; just, I thought I had noticed it had mostly gone in this direction)
alserio 7 hours ago [-]
I was surprised, that was not my impression at all. But thank you for your answer!
claytongulick 9 hours ago [-]
I've been writing code since the 80s, professionally since the mid 90s, in almost every major language, platform and operating system, from 8 bit microcontrollers to large scale web platforms.
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?
samtheprogram 12 hours ago [-]
....they did ...and... the camp still exists
ajkjk 12 hours ago [-]
well, as I said, I don't take them seriously :p
12 hours ago [-]
dimitropoulos 14 hours ago [-]
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 ;)
hoppp 13 hours ago [-]
I am not sure a rust rewrite would be meaningful.
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.
afdbcreid 11 hours ago [-]
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.
nicoburns 12 hours ago [-]
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.
dimitropoulos 13 hours ago [-]
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.
Yes, I saw the YouTube video about Jevons paradox from Hank Green yesterday. :)
annjose 11 hours ago [-]
The Jevon's Paradox. And it is not a paradox :-)
regular_trash 3 hours ago [-]
It actually is a paradox, a veridical paradox. But I'm splitting hairs lol
hebrox 12 hours ago [-]
*The
faefox 12 hours ago [-]
Fine, the Hank Green.
tancop 11 hours ago [-]
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.
DonaldPShimoda 14 hours ago [-]
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!)
dimitropoulos 14 hours ago [-]
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
samuell 12 hours ago [-]
Steve Francia (author of Hugo and a bunch of other top Go projects) wrote up some thoughts of Go's fit in the agentic era:
> 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.
mejutoco 11 hours ago [-]
> for the most advanced type system known to mankind
Honest question, what do you mean by this?
culi 8 hours ago [-]
It means they really like TypeScript and they hope to influence some juniors into investing themselves into it
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.
giraffe_lady 11 hours ago [-]
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.
tshaddox 13 hours ago [-]
> 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)?
whilenot-dev 11 hours ago [-]
I don't think GP was referring to transpilation speed when they wrote "most advanced type system known to mankind".
tshaddox 11 hours ago [-]
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.
dimitropoulos 7 hours ago [-]
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.
miiiiiike 12 hours ago [-]
After a few years of using Typescript, having to use type annotations and import basic language features like `abc` in Python feels like an absolute slog.
chroma_zone 12 hours ago [-]
I'm glad the JSDoc type syntax is still getting some focus. It's my favorite way to use typescript in my own projects. Some of the syntax changes will be annoying to update but most of them seem to be for the better.
raddan 12 hours ago [-]
I'm glad that TypeScript uses JSDoc and not the hideous XML format [1] that Microsoft's other languages use.
I'm a big C# fan but XML docstrings definitely suck.
We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.
skybrian 12 hours ago [-]
No TypeScript compiler API yet, but I'm encouraged to hear that they're working on it.
simlevesque 12 hours ago [-]
It's coming in 7.1
stymaar 12 hours ago [-]
Performance improvements, yay !
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.
dabinat 2 hours ago [-]
I think Rust is noticeably slow for two reasons:
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.
I didn’t care. Because to me the performance was a cost I was more than willing to pay for giving me sanity in JS land. Knowing you were passing the right types, right number of arguments, etc. Just the quality of documentation you got from having types at all above the nothing we had before was huge.
I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
appplication 12 hours ago [-]
As a TS dev, it’s probably because we already have such a high pain tolerance and low expectations.
notnullorvoid 9 hours ago [-]
Performance of tsc wasn't an issue for small projects, and for larger projects it could be fixed by using incremental build option, and/or TS project references. Most either didn't care enough about the perf or were too lazy to set it up. TS7's perf boost will give people less of a reason to use these options.
dzonga 9 hours ago [-]
congrats to the typescript team.
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.
mckee_plus_plus 8 hours ago [-]
Major ts pain point is scoping tsconfig settings for lib and types configurable for subsets of a project.
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.
paustint 7 hours ago [-]
Agree it is a pain. I have been using nx and it handles all that for you, playwright is a separate project with it's own twconfig and they all inherit from a root tsconfig.
I prefer nx for single applications and move shared code to "libraries" (I use non-buildable libs). It's pretty sweet for larger projects.
linzhangrun 5 hours ago [-]
Congratulations! Although I'd prefer the C# authors to rewrite it in C# AOT :)
anankaie 4 hours ago [-]
Or implement tsaot
jeswin 4 hours ago [-]
Congrats on launch. The code is beautiful, and the test suite is quite solid.
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.
lioeters 3 hours ago [-]
That tsts project looks very interesting. I suppose there are various practical reasons for doing this. For me I'm just glad to see an easy way to run the newest TypeScript compiler (and I guess type checker?) in the browser. There's an unofficial Wasm build of tsgo/ts7, if I recall was about 12Mb. Another advantage of tsts I imagine is the ease of diving into the compiler internals as it's running (interpreted) instead of a binary distribution, another language (though I like Go), or having to recompile it on every change. Good luck with the project, I'll be keeping an eye on its progress with interest.
Exoristos 12 hours ago [-]
Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?
semiquaver 11 hours ago [-]
For one, you’re not using TypeScript server-side. Whatever execution engine you are using is executing transpiled or JavaScript.
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.
recursive 9 hours ago [-]
This is build-time performance, not run-time.
throw310822 10 hours ago [-]
Because you can share types and even modules with your frontend project? Because for applications that aren't CPU-intensive it makes almost no difference? Because you are familiar with it and like it? Because of the humongous amount of libraries?
thunderfork 8 hours ago [-]
Whether the performance difference between Go and JS (via node or whatever) matters depends on your use case - it definitely matters for the TS compiler, but it might not matter at all for your CRUD app.
Scarbutt 10 hours ago [-]
Because it’s easier to work with one main language if you can get away with it.
austin-cheney 7 hours ago [-]
Fascinating, but since Node now natively strips the TypeScript type annotations I rarely run the TSC. I really only run it now when I make a major regressive change and need static output from the compiler to see things I have failed to update.
Even for front end code destined for the browser I rely on Node's type stripping.
MiTypeScript 7 hours ago [-]
fair, but, at the same time.. you may not think too much about it, but your editor is running the TypeScript language server all day long. presumably, so does your CI. presumably, so does your AI agent before feeling good about what it just did.
NetOpWibby 12 hours ago [-]
The speed-up improvements are incredible, can't wait for this to rollout to Deno. Everything I build uses TypeScript so I'm excited to see just how quick my apps compile.
MoonWalk 10 hours ago [-]
I was wondering how this kind of change makes its way into environments like Deno. I'm building a project on Deno too.
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?
skybrian 10 hours ago [-]
Deno resolves import statements in its own way. For example, you can import URLs and JSR packages directly, but the file is usually loaded from Deno’s global module cache. To resolve imports you need to look at the deno.json file and deno.lock file. They also added Deno Workspaces (monorepos) which adds more complexity.
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.
VerifiedReports 20 minutes ago [-]
Thanks for the reply. I don't understand what a TypeScript version bump has to do with import statements, though.
I remember going from Java in IntelliJ straight to TypeScript at work for another project, and I recall how _slow_ everything was in the editor(s). I have been using TypeScript 7 RC and most of my complaints have gone away with regards to speed.
perrohunter 11 hours ago [-]
For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?
herpdyderp 10 hours ago [-]
Depends on your tooling. I can't update yet due to ESLint package dependency mismatches. I'll have to wait for all the ESLint plugins to update. There may also be new failures in your code from the v6 to v7 update. I had only a very minor one though in my initial test.
dmix 7 hours ago [-]
Eslint is like an anchor on upgrading anything (including Eslint itself). I'll be happy to move on from it.
sheept 11 hours ago [-]
It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.
lelandfe 11 hours ago [-]
If you’re continuing to use the previous version in CI, there’s no reason to not use this locally. It’s a tremendous speed upgrade.
herpdyderp 10 hours ago [-]
The reason to not use it locally is false negatives or false positives compared to your CI version. Your local tsc will not match the results of your CI tsc.
12 hours ago [-]
willchen 13 hours ago [-]
really excited to see this release! i've been using TypeScript for several projects like https://github.com/dyad-sh/dyad which is >250k lines of TypeScript and the speed-up makes things like running typescript check as a pre-commit hook painless
thanks DanRosenwasser and team for building such an awesome tool for so many years!
12 hours ago [-]
settled 7 hours ago [-]
Great links but unfortunately it doesn't work with ts-jest out of the box, had to do the side-by-side compatibility workaround. Major releases should give more confidence for common tools like testing instead of pointing backwards
ksec 10 hours ago [-]
I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?
fishgoesblub 11 hours ago [-]
Are these performance improvements just for transpiling the Typescript to JS, or actually running programs written in Typescript?
culi 8 hours ago [-]
TypeScript isn't a runtime language
tpetry 11 hours ago [-]
These are for type-checking. Transpiling takes barely any time.
herpdyderp 10 hours ago [-]
I'm only seeing a speedup of 4x compared to v6, but I'll take it!
brikym 5 hours ago [-]
3 - 3.5x here. I'm very happy with that though.
terpimost 12 hours ago [-]
Are there any plans about wasm version?
spankalee 12 hours ago [-]
Yes, but no official builds yet that I know. This is a really important issue for online playgrounds and IDEs.
jakebailey 12 hours ago [-]
Hoping to start getting Wasm builds out soon; it's a little unclear what people want when they say "Wasm", because it could mean
- 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
notnullorvoid 9 hours ago [-]
I think all 3 are pretty important for using TS in online sandboxes and IDEs.
raddan 12 hours ago [-]
I am a little surprised that they rewrote the compiler in Go instead of just compiling the existing compiler to WASM. The linked announcement does not talk about a WASM alternative at all (rewriting a compiler is a risky move!). Does anybody know what the rationale was to do a full rewrite? The article really emphasizes speed, but not much else. Was it Go's concurrency affordances that made the switch worthwhile?
jakebailey 12 hours ago [-]
The compiler was written in TS; it wouldn't make much sense to compile TS to Wasm, only to have that same code run in the same interpreter as the JS code.
I've been waiting for this for a long long time. Congrats on the release.
austinthetaco 11 hours ago [-]
I'm still not sold on typescript. I've used it off and on professionally for years and 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. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you technically can do functional programming (but as i said its a pain) and YES its optional and you dont have to use it everywhere, but try pulling that maneuver on a technical team "lets use typescript where we each feel like it".
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.
drschwabe 6 hours ago [-]
Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase.
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.
ameliaquining 6 hours ago [-]
Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.
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.
jakubmazanec 11 hours ago [-]
> I am still of the opinion that well organized and named JS is all that anyone needs
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.
austinthetaco 11 hours ago [-]
You really should just not assume things about people with no reason other than "they dont like the things i like so therefor they must not be experienced". I've worked on plenty of very very large codebases with large teams.
> 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#.
jakubmazanec 10 hours ago [-]
> You really should just not assume things about people with no reason other than "they dont like the things i like
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).
austinthetaco 8 hours ago [-]
Its not essential. Good organization. Good functional configuration. Proper separation. Good variable naming. All of these things are what make it more than easy to work without type declaration. People have been working on huge code bases without types for a VERY long time with no issue, especially in functional paradigms.
tomnipotent 8 hours ago [-]
> You really should just not assume things
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.
austinthetaco 8 hours ago [-]
They have said time and time again it was because their C# team was writing frontend code in a huge codebase and wanted similar support.
tomnipotent 8 hours ago [-]
No they haven't. It's been said time and time again that their teams were struggling with large JS code bases for Bing Maps and O365 web apps.
shafiq235 3 hours ago [-]
Its the best thing ever. I have been waiting months for this
Thanks to Microsoft for the first - NON SLOP release
pmkary 10 hours ago [-]
Glorious Day!
11 hours ago [-]
devtoolsuite 11 hours ago [-]
[flagged]
zigae 3 hours ago [-]
[flagged]
gokulrajaram 6 hours ago [-]
[flagged]
shimman 11 hours ago [-]
[dead]
MiTypeScript 14 hours ago [-]
sub-1day-first-frame-of-DOOM LFGGGGGG
blurb2023 12 hours ago [-]
finally it uses a normal language backend =)
m_ke 10 hours ago [-]
After running out of Fable credits in a day on my max plan I started looking around for ways to trim down my token usage and came to the realization that all of the type spaghetti that opus wrote is probably eating up like 50-70% of my tokens.
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.
jw1224 10 hours ago [-]
Interesting, I've come to the opposite conclusion: a lack of types (or types that are only weakly enforced) costs me significantly more tokens in the long-run to maintain, and makes it far too easy for models to silently introduce bugs.
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!)
kodama-lens 10 hours ago [-]
In a world where code generation is cheap, why use untyped languages?
Types add confidence, stricter interfaces, and most likely a better runtime performance.
m_ke 10 hours ago [-]
With agentic coding the costs of tokens compound with each message / tool call and etc. Having to load in and update large files makes things slower and way more expensive.
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).
IceDane 10 hours ago [-]
Why not just do like.. actual engineering, and stay in control of what the LLM builds?
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?
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.
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.
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.
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.
I love TypeScript, if nothing else for how it's been able to popularize types.
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.
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:
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:
There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can: Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.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:
And the programmer need never specify what x and y are, as long as there exists a reachable declaration of operator+ that has two arguments that accepts whatever x and y resolve to, at instantiation time (which is compile time).So:
i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't.> 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.
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.
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.
> 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.
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...
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.
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
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.
> 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?
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.
"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.
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.
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...
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.
Me when my manager asks to complete the JIRA ticket.
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.
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?)
edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.
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.
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 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.
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!
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.
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...
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.
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?
huge congrats to the team!
looking forward to the Rust rewrite ;)
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.
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.
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.
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
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.
(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
https://spf13.com/p/go-the-agentic-language/
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.
Honest question, what do you mean by this?
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.
[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.
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.
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...
I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
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.
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.
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.
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.
Even for front end code destined for the browser I rely on Node's type stripping.
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.
thanks DanRosenwasser and team for building such an awesome tool for so many years!
- 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
And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...
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.
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.
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).
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.
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).