TypeScript 7

> 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?

> 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.

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.

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 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.

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

> 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.

....they did ...and... the camp still exists

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.

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

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

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

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

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

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?