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).
jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that.
in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types.
the difference is with roads you dont get a lot of good secondary effects, one lane is just like the next. benefits are linear with the cost so they balance out. but with typescript and software in general they can be exponential.
fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.
The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance.
It probably won't ever happen though.
> It's easy to reimplement typescript in go 1:1 just by looking at the code.
That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.
Can you elaborate why that's a factor? The tools are just binaries in how they're used, the language they're written in is no longer a factor then.
It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.
They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.
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.
> most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out)
This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?
The original poster was referring to the golang port of TypeScript which was done almost exclusively for performance reasons. They weren’t just making an unprompted comparison of two type systems.
I was referring to the type system in the formal "specification" sense, not the implementation details of the compiler, such as the compiler's runtime (Go, or, in the past, JavaScript/Node). it's too bad there's no specification for TypeScript the way there is for JavaScript and many other things (most?). in that sense, the performance of the type system is uncoupled from the semantics of the type system itself (as the Go port has thoroughly illustrated!).
I mentioned Hindley-Milner because I am under the belief that the HM system (as in OCaml) is, in the same formal/semantic/specification sense, perhaps more advanced. but, as is often with these things, the rubber meets the road on which one of them has been shown to actually run Doom, lol, to which TypeScript is currently the undisputed king.
> in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust
imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
I'm reading a lot of style / flavor / quality / vibes in your reply, something that will be different between every developer (for the most part); the thing with Go is that there's a lot less of that in the wider ecosystem.
They picked Go after meaningfully considering Rust (and others). I don't remember all the reasons for it but it was detailed in the original blog post.
There's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads:
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.
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!
> 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.
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
> 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.
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.
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...
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.
The concept of them being more than compiler bookkeeping, but as propositions about program behavior and invariant encoding is more than 50 years old at this point.
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.
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?)
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.
Wow, never heard about Sorbet before, looks good! I was a Ruby developer around ten years ago, and never stopped liking the language. I have moved into functional programming since, with strong types like Haskell, and do appreciate compile time type checking nowadays. Sorbet seems like a nice compromise here though!
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.
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.
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.
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).
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.
Note that Python supports type annotations in its syntax, but the interpreter will just ignore them as they are meant to be used by external tools such as ruff: https://github.com/astral-sh/ruff
I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.
You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.
Definitely mypy keeps my sanity in a relatively large Python project I'm working on :). But I don't believe Python actually assigns any meaning to them, and at times mypy and e.g. pyright may disagree on what the types actually are.
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.
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.
Saying a variable is of type pointer to any value instead of just any value doesn't make a difference for the semantics (except in some bad cases, like default parameter values).
> It's also pragmatic...
So it's almost like Javascript. That something is not a source of bugs, is not proof of strong typing. Python uses type information in some cases, that's it. E.g., it's trivial to load some record or file of the wrong type, and only find out much later. That's a real source of very unpleasant bugs.
But by most people definitions, Python certainly is NOT strongly typed.
My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs.
It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.
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".
the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.
> I'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.
> 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 one of those, but what I mean is that there are no static types you (and the compiler) can reason about.
Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as logical propositions like in ML, which highly influenced modern type systems.
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.
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?
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.
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.
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.
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.
The "or" (and "and") types in TypeScript are set theoretic rather than algebraic, so they don't require wrapping and unwrapping. It seems to me that they are the ones with better ergonomics.
It sounds neat when you phrase it that way but my decade of professional experience in typescript has not shown it to be the case in practice. ymmv I guess.
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.
You can go a long way with just javascript, eslint and prettier if you work solo, but IME work is a low-trust environment which means that either you're a wolf and you do what you want or you have to use C# and enable nullable checks.
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...
> 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.
And by 2004 the browser wars where long over. That was the period when Microsoft left the web languishing on IE6 after destroying all competitors and then promptly disbanding their browser team. Firefox only got its name in 2004 and was released at the end of that year.
Ever wondered why, even on modern websites, css is riddled with repeated statements with this weird "moz-" prefixes?
In 2006 when working at Wikia I wrote a tiny lib for deep linking.
The lib started at 25 lines with naive implementation of the documentation.
Two weeks later when I had all browsers on all operating systems mapped out it was close to 1,000 lines.
I've spent half of my coding time working with Flash, and the monopoly was great. You could make a layout, write a code and have absolute certainty that the outcome will look and feel exactly the same regardless if you ran it on desktop, in the browser - any browser, mobile or kiosk.
Few years later I did UI for The Witcher and Dead Island and with that you can add xbox and playstation to the list.
Last time I did some web programming was 3 years ago, but it was still a far cry from that experience.
My father took me to that conference so that would be closer to 2000 or 2001.
Fun fact, around that time I attended 3 "microsoft summit" - that was the name of the event - and every time the absolute banger, booked out months before the event, was a workshop with a guy who specialized in optimizing windows licensing for enterprise.
That was still the time when MS charged per CPU on servers, and the guy used to give couple seemingly basic scenarios and asking crowd how would they deal with licenses. Every time his version was 3-4x cheaper than what you would think of.
God, do you remember that presentation Google gave when they introduced Angular 2.0? I think it was December 2015. It was sooo bad that in my eyes it killed Angular's momentum almost completely. I am surprised that it is still around actually. Can't find it anywhere though. Google must've censored it of the internet :)
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...
That is a very charitable read. I remember plenty of dumbasses who said: I don't need a type system, cause I know what I am doing and I don't create bugs.
It's important to remember that at no point was there a pendulum swing per se, that is, only few actually ported their Java code to Python for example.
The discussions and articles online seemed to infer that, but that's uh. media bias? Hype? Things written about and things you read online are not the full story, is all.
I would chose typescript over js, Python and perhaps ruby. but I would use Scheme over typescript. I would probably use f# or ocaml over Scheme for most projects.
I've seen TS hurt more than help in many cases, because people think types define the world, and then they get malformed JSON (or just a new structure) and their world crumbles.
Yes, it's a skill issue, but oh dear the amount of developers who have that issue.
How does TS make these situations worse? Seems to me that it helps a ton with identifying and fixing these issues. Either you can get away with just replacing the assertions with type guards, or you'll have to refactor some stuff (which is also much easier with types).
I'm glad the JSDoc syntax is still getting some focus. It's my favorite way to use tsc in my own projects. Some of the syntax changes will be annoying to update but most of them seem to be for the better.
This is my biggest annoyance with c#. I've always wanted to try to add jsdoc or something in the compiler. Little more annoying than having to use > and < in a comment
It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.
I 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.
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.
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.
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.
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 in your import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the module resolution code is in Rust.
I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
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.
> I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.
I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.
"In their right mind?" I wouldn't start a project in anything other than TypeScript now. My platform is a monorepo across web and native mobile (Expo), and is TypeScript throughout. All my types flow everywhere automatically. Even the shape of a database table is shared with the native app with tRPC. Nothing can break the type contract anywhere. How would you do that with another language?
Absolutely everyone who doesn't work with hardware, or on specific problems, because it's far more popular, easy to hire for, easy to deliver an MVP with and easy to have people jump between frontend and backend with. I'm saying this as someone who specialized in .NET before and now writes Node/TS. I simply grew out of the opinion that language/architecture is everything. When you make a product delivering quicker matters more than choosing a marginally more performant language, unless you're solving a very specific problem that requires that performance. Adding one more server costs less than hiring engineer for a more niche language and if you have the success that requires you to scale up that much, money is probably not the problem anymore. Granted we're in LLM era where everyone can write anything but it's still better to have people vibe in language they actually know, so they understand what's happening. You can always extract services later on and rewrite them in a more performant way, noone's stopping you.
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?
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.
For various definitions of "strong". People (ab)use pointers to hack in nil support, and the type system can't perform nil checks for you, so you still end up with runtime errors if you're not careful enough.
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.
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.
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.
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.
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.
I've been really, really happy with oxlint. It has all the rules I usually need and the configs etc. tend to just work, whereas I don't know how much time I spent getting ESLint to work in slightly more complex repo setups.
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?
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.
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.
The irony is that the blog post actually points out as pain points the reasons many of us assert languages like Zig are out of place in the 21st century.
A nice collection of heap-use-after-free crash, use-after-free crash, crash and out-of-bounds read, memory leak, double-free crash, race condition crash.
Bun is infrastructure. Why would I want my infrastructure to be unstable? (By the way, 10,000 unsafe blocks last I checked, though the number is going down somewhat.)
I've never used bun on production for this very reason. But nevertheless, tens of thousands of people and businesses do.
And I'm not sure how you're responding to my comment. The parent said "this is a marketing stunt" derogatorily, as if it's slop that doesn't work. This is already the canary build, it's more stable than the current stable, and is actively in production products in wide use.
The parent is objectively wrong, whether or not I personally use Bun.
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.
Probably cheaper than doing it by hand, however, that's the short term "port x to y" cost, the longer term cost (or benefit) is a lot harder to calculate.
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.
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 really not even close to being the same. In the best case, a bug means your app crashes on the new version. In the worst case, something more insidious happens like opening a security vulnerability (say, TLS isn't handled correctly or HTTP headers are mishandled in a way that allows SSRF or request smuggling) or a previously linear time operation is accidentally quadratic (leading to DoS).
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.
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
> 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)
> 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.
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.
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!)
In a world where code generation is cheap, why use untyped languages?
Types add confidence, stricter interfaces, and most likely a better runtime performance.
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).
243 comments
[ 4.1 ms ] story [ 97.9 ms ] threadhuge 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.
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.
It probably won't ever happen though.
> It's easy to reimplement typescript in go 1:1 just by looking at the code.
That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.
It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.
They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.
But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?
I mentioned Hindley-Milner because I am under the belief that the HM system (as in OCaml) is, in the same formal/semantic/specification sense, perhaps more advanced. but, as is often with these things, the rubber meets the road on which one of them has been shown to actually run Doom, lol, to which TypeScript is currently the undisputed king.
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.
The blog post: https://devblogs.microsoft.com/typescript/typescript-native-...
Why Go? https://github.com/microsoft/typescript-go/discussions/411
Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410
Honest question, what do you mean by this?
thanks DanRosenwasser and team for building such an awesome tool for so many years!
I love TypeScript, if nothing else for how it's been able to popularize types.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs. But a codebase in production is unlikely to have much type related bugs...
I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.
The concept of them being more than compiler bookkeeping, but as propositions about program behavior and invariant encoding is more than 50 years old at this point.
What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing.
(Just checked sorbet landing page, looks like it's mainly/only for fn signatures?)
A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.
Me when my manager asks to complete the JIRA ticket.
There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.
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”?
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).I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.
You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.
So:
i 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.
> It's also pragmatic...
So it's almost like Javascript. That something is not a source of bugs, is not proof of strong typing. Python uses type information in some cases, that's it. E.g., it's trivial to load some record or file of the wrong type, and only find out much later. That's a real source of very unpleasant bugs.
But by most people definitions, Python certainly is NOT strongly typed.
My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs.
It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.
for the record - I agree completely.
(glad people are over the unicode thing!)
the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.
I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.
Get the f*ck outta here.
Come on, that was very clearly what he was talking about. No need to be this pedantic.
I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about.
Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as logical propositions like in ML, which highly influenced modern type systems.
> 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.
No. There's been GC-less Lisp's over the years, here's a good paper on one: https://dl.acm.org/doi/10.1145/142137.142162
There was also pre-Scheme, GOAL, nowadays there's Carp and Dale. Zeta Lisp (and now SBCL) had/have arenas and you can manually allocate, etc...
Functional programmers keep hyping up ADTs like this but the normie programmer doesn't care about ADTs or immutability. What really brought back static types was Golang & typescript, both have local variable type inference, good IDE support & other tooling, and (at least superficially) lighter weight syntax than Java. Normies don't care about algebraic types, pattern matching, immutability, referencial trasparency, type classes. What matters is libraries and tooling.
Why certain approaches didn't catch on until recently, or ever, is an interesting thing to think about but "we didn't know how" is not the story here.
That's the difference between "having a typing error" and "having an error due to typing".
well kinda
Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
"x = " and there are only two variables in the scope with the same type so IDE will present them to you in a drop down and you can already think about the next line.
Fast forward to ~2015 when I'm working on Angular project. The whole idea feels like a caricature Chinese whispers of an OOP framework. Each component is divided into three files, all of them have to identify themselves using a magic string, and that string has to be manually entered into each file.
There are couple of type systems, like the one from Facebook, but no one is using them. And everyone claims that OOP and types are the thing of the past.
Part of that corelates to a joke I was making back in 2013, soon after Apple killed Flash and everyone started doing JS everywhere. Major companies where posting job offers for senior javascript devs asking for 5-7 years of experience. But someone who was doing JS for 7 years in 2012 has all his career focused around gluing together jquery plugins.
Anyway, I'm as well glad that we finally did a full circle and finally have some sanity in the industry...
> Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
> Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
I think you’re off by at least 6-7 years. Visual Studio had autocomplete since at least version 6. And yes it was magical the first time you experienced it.
Ever wondered why, even on modern websites, css is riddled with repeated statements with this weird "moz-" prefixes?
In 2006 when working at Wikia I wrote a tiny lib for deep linking.
The lib started at 25 lines with naive implementation of the documentation. Two weeks later when I had all browsers on all operating systems mapped out it was close to 1,000 lines.
I've spent half of my coding time working with Flash, and the monopoly was great. You could make a layout, write a code and have absolute certainty that the outcome will look and feel exactly the same regardless if you ran it on desktop, in the browser - any browser, mobile or kiosk.
Few years later I did UI for The Witcher and Dead Island and with that you can add xbox and playstation to the list.
Last time I did some web programming was 3 years ago, but it was still a far cry from that experience.
My father took me to that conference so that would be closer to 2000 or 2001.
Fun fact, around that time I attended 3 "microsoft summit" - that was the name of the event - and every time the absolute banger, booked out months before the event, was a workshop with a guy who specialized in optimizing windows licensing for enterprise.
That was still the time when MS charged per CPU on servers, and the guy used to give couple seemingly basic scenarios and asking crowd how would they deal with licenses. Every time his version was 3-4x cheaper than what you would think of.
It's more common on consultancy than product companies.
Consultancy is getting paid for doing things. Product company is getting paid for getting things done.
I don't enjoy writing it, but I don't mind to maintain it, all apps have a predictable architecture.
Performance wise it's also quite good and way better than others out of the box.
My read is that people were never really against types: they were against type systems that got in the way. Older ones often weren't expressive enough, so you ended up writing verbose patterns just to appease the compiler.
That's why dynamic languages gave startups a sizable velocity edge for a while. Modern type systems (with optionals, unions/sum types, inference, etc.) are completely different.
To paraphrase a comment I once read here on Hacker News: I'll take static typing with sum types over dynamic typing, but I'll take dynamic typing over static typing without sum types...
The discussions and articles online seemed to infer that, but that's uh. media bias? Hype? Things written about and things you read online are not the full story, is all.
it is not an either or.
Yes, it's a skill issue, but oh dear the amount of developers who have that issue.
At worst, TS can only really be as bad as JS, no?
[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.
I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds.
Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…
1. The default settings aren’t well optimized. So the pattern a lot of people fall into is: start a project and everything’s fast, then add more code and dependencies and everything gets super slow. Then you Google how to fix it, change some compile settings and restructure your project and it speeds up again. Rust requires knowledge and effort to keep compile times reasonable - it’s not set up that way by default.
2. Rust Analyzer / cargo check is inefficient and throws a lot of data away each time instead of caching it. So in a larger project you’re waiting on it to catch up. Waiting on Rust Analyzer to check my code is easily the largest amount of time wasted, more so than actually compiling it.
But it should be said that this is being worked on: https://rust-lang.github.io/rust-project-goals/2025h2/relink...
How does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?
This means you need to plug in your import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the module resolution code is in Rust.
I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.
I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.
WASM
All my side projects for the last year+ have used full stack Rust.
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.
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.
Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?
Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way.
Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
A nice collection of heap-use-after-free crash, use-after-free crash, crash and out-of-bounds read, memory leak, double-free crash, race condition crash.
And I'm not sure how you're responding to my comment. The parent said "this is a marketing stunt" derogatorily, as if it's slop that doesn't work. This is already the canary build, it's more stable than the current stable, and is actively in production products in wide use.
The parent is objectively wrong, whether or not I personally use Bun.
Yes, but that doesn't mean it wasn't also "helped" along by AI.
See:
1. https://github.com/microsoft/typescript-go/pull/1387
2. https://github.com/microsoft/typescript-go/pull/2978
3. https://github.com/microsoft/typescript-go/pull/1138
4. etc...
Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.
---
The initial port was automated, then devs got in there, then LLMs got in there.
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.
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).