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
TypeScript 7
161–170 of 321 posts
Re: TypeScript 7
#162Earlier quoted context omitted.
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 mira…
Not sure I understand. Bun's changes are merged on the dev branch and available for use, no?
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.
Re: TypeScript 7
#163Fascinating, 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.
Re: TypeScript 7
#164Earlier quoted context omitted.
I don't think GP was referring to transpilation speed when they wrote "most advanced type system known to mankind".
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.
Re: TypeScript 7
#165the 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 ;)
> for the most advanced type system known to mankind Honest question, what do you mean by this?
I answered here https://news.ycombinator.com/item?id=48838629
Re: TypeScript 7
#166Major 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 outpu…
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.
Re: TypeScript 7
#167Fascinating, 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.
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.
Re: TypeScript 7
#168Earlier quoted context omitted.
Spaces over tabs? Since when?
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)
I was surprised, that was not my impression at all. But thank you for your answer!
Re: TypeScript 7
#169For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?
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.
Eslint is like an anchor on upgrading anything (including Eslint itself). I'll be happy to move on from it.
Re: TypeScript 7
#170Earlier quoted context omitted.
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.
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 definit…
My understanding of weak typing is about allowing automatic type conversion. “3” + 1 === “31”, 1 + “3” === 4. Strong typing doesn’t auto convert.