Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 7

devblogs.microsoft.com

Post reply on HN
Print view View original

301–310 of 321 posts

Re: TypeScript 7

#301

Post by bastawhiz »

vlovich123 wrote: post #291
bastawhiz wrote: post #290

Earlier quoted context omitted.

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

You can apply the same FUD to the old version. Your argument basically is “all change brings risk” which is true but doesn’t add any useful insight. It’s always easy to complain and warn about change causing problems while ignoring the problems of the status quo. The “everything is fine” meme in action.

Sure, all change brings risk. But this is change where:

1. The change isn't made by a human.

2. The change wasn't fully reviewed by humans or machines. It's not currently possible for a machine to review the whole thing as one.

3. It's a full rewrite. This isn't a ten thousand line change, it's multiple orders of magnitude more than that.

You're literally making the argument that all risk of any size from any change of any size is equivalent, so just don't worry about it. If you relied on this software before, good luck convincing yourself it's fine to rely on this software now: it's literally not the same software anymore.

Re: TypeScript 7

#302

Post by zeroq »

epolanski wrote: post #277
lobofta wrote: post #241

Earlier quoted context omitted.

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 :)

Angular is super used across the industry. It's more common on consultancy than product companies.

And that's probably a product of different incentives.

Consultancy is getting paid for doing things. Product company is getting paid for getting things done.

Re: TypeScript 7

#303

Post by Timon3 »

techpression wrote: post #298
adamddev1 wrote: post #14

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.

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

At worst, TS can only really be as bad as JS, no?

Re: TypeScript 7

#304

Post by techpression »

Timon3 wrote: post #303
techpression wrote: post #298

Earlier quoted context omitted.

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). At worst, TS can only really be as bad as JS, no?

The illusion of safety.

”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.

Re: TypeScript 7

#305

Post by adamddev1 »

techpression wrote: post #304
Timon3 wrote: post #303

Earlier quoted context omitted.

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). At worst, TS can only really be as bad as JS, no?

The illusion of safety. ”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.

That sounds like people who don't understand anything about the messiness at the boundaries of the program. Just because there's a type defined, it doesn't mean that the data from the outside world will fit that type.

Re: TypeScript 7

#306

Post by andai »

Tadpole9181 wrote: post #162
docmars wrote: post #143

Earlier quoted context omitted.

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…

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

Re: TypeScript 7

#307

Post by Timon3 »

techpression wrote: post #304
Timon3 wrote: post #303

Earlier quoted context omitted.

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). At worst, TS can only really be as bad as JS, no?

The illusion of safety. ”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.

You say that as if inexperienced devs would naturally drift towards doing data validation without TS, but that hasn't been my experience. Instead what I used to see were lots of unnecessary/repeated checks spread throughout most source files (and which frequently didn't catch the actually problematic cases), which I've seen much less frequently in TS projects.

Even without TS, I'd be using zod (or a similar library). I haven't had any issues with zod's bundle size, and I don't see a good reason to write custom encoders/decoders everywhere.

Re: TypeScript 7

#308

Post by nicoburns »

Cthulhu_ wrote: post #272
nicoburns wrote: post #10

Earlier quoted context omitted.

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 f…

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.

> The tools are just binaries in how they're used

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.

Re: TypeScript 7

#309

Post by hvb2 »

Xixi wrote: post #208
egorfine wrote: post #82

Earlier quoted context omitted.

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

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…

> Even if they make it to prod, they won't survive long...

I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.

Re: TypeScript 7

#310

Post by vlovich123 »

bastawhiz wrote: post #301
vlovich123 wrote: post #291

Earlier quoted context omitted.

You can apply the same FUD to the old version. Your argument basically is “all change brings risk” which is true but doesn’t add any useful insight. It’s always easy to complain and warn about change causing problems while ignoring the problems of the status quo. The “everything is fine” meme in action.

Sure, all change brings risk. But this is change where: 1. The change isn't made by a human. 2. The change wasn't fully reviewed by humans or machines. It's not currently possible for a machine to review the whole thing as one. 3. It's a full rewrite. This isn't a ten thousand line change, it's multiple orders of magnitude more than that. You're literally making the argument that all risk of any size from any change…

No I’m not making that argument, you’re the one making that claim as if it’s the only alternative to your position.

My position is more nuanced. A) what does the test coverage look like B) how is the deployment managed.

I suspect B is going to be my biggest issue - normally you’d deploy this slowly over time to monitor problems and whatnot. But ultimately the real test is seeing how it actually performs in the wild and kinds of problems people report. But you can always keep using the zig version if you wanted. So ultimately it’s a lot of consternation over a nothing burger. You can laugh at them if they screw up the release, but it’s a bold attempt at trying something legit. It took Microsoft 2 years of many engineer hours migrating typescript to Go. If it takes significantly less calendar time and human time, you could reasonably even evaluate what a Rust based typescript looks like vs Go if you wanted to for an order of magnitude cheaper.

Post reply on HN