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

291–300 of 321 posts

Re: TypeScript 7

#291

Post by vlovich123 »

bastawhiz wrote: post #290
vlovich123 wrote: post #223

Earlier quoted context omitted.

inevitable: https://xkcd.com/1172/

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.

Re: TypeScript 7

#292

Post by giraffe_lady »

cubefox wrote: post #244
giraffe_lady wrote: post #183

Earlier quoted context omitted.

Algorithm W is 40 years old and HM has vastly better ergonomics than TS's types. Why certain approaches didn't catch on until recently, or ever, is an interesting thing to think about but "we didn't know how" is not the story here.

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.

Re: TypeScript 7

#293

Post by Tadpole9181 »

moogly wrote: post #283
Tadpole9181 wrote: post #162

Earlier quoted context omitted.

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…

A minor version bump? Exciting times we live in.

What exactly is your complaint? It doesn't make any breaking changes. That's how semantic versioning works.

Re: TypeScript 7

#294

Post by ShinyLeftPad »

sharlos201068 wrote: post #287
ShinyLeftPad wrote: post #232

Does lack of compiler API mean typescript-language-server is not going to play nice with 7.0?

I remember reading they're rebuilding it to use the same LSP as other languages instead of its custom thing.

it's not? pretty sure I use typescript-language-server as generic LSP from my editor for years

Re: TypeScript 7

#295

Post by ajkjk »

horsawlarway wrote: post #50
ajkjk wrote: post #39

Earlier quoted context omitted.

completely agree. but I felt like even then it was clear that types were a good idea and the implementations were not. For instance I started programming on Java 4 or 5 and the types were pretty bad---but still it was obviously the right way to go compared to JS or, god forbid, shell.

> but still it was obviously the right way to go compared to JS or, god forbid, shell. I just don't think this is true. Frankly - it's hard to argue this at all (even today) given that JS is the dominate language on the planet, and it lacks types... as does python, which had a reputation for decades as THE language to use to teach new folks to code. Or take PHP which dominated server development for a LOOONG time: al…

JS was popular despite its lack of types, not because of them. If a typed language had been bundled into browsers from the beginning then we would not be shimming types into it with TS today (although I'm sure there would be other difficulties).

When companies started making enterprise-scale JS applications they had to solve for the type story because it is unmaintainable otherwise. TS is the winner in a long line of iterating on that problem.

Re: TypeScript 7

#296

Post by magicalist »

koolba wrote: post #202
zeroq wrote: post #186

Earlier quoted context omitted.

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 , , arrow keys and . "x = " and ther…

> 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 , , arrow keys and . I think y…

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.

Re: TypeScript 7

#298

Post by techpression »

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.

Re: TypeScript 7

#299

Post by skybrian »

plasticeagle wrote: post #266

I love Typescript, I think it's a fascinating language with a great runtime. It's already very fast to execute, but the compile times have been awful. Especially when you start to run production builds with minification and whatnot. So I'm interested on what exactly has been sped up here. I can see compile times have been, but is that it? I suppose the runtime itself was always native code, and already very fast.

The TypeScript compiler is (was) slow, but you don’t need it to minify code. This sounds like some other problem with the tools in your project’s build. (There are faster tools available these days.)

A faster type checker will help with performance problems in text editors since type info is needed for a lot of queries.

Re: TypeScript 7

#300

Post by skybrian »

VerifiedReports wrote: post #224
skybrian wrote: post #102

Earlier quoted context omitted.

Deno resolves import statements in its own way. For example, you can import URLs and JSR packages directly, but the file is usually loaded from Deno’s global module cache. To resolve imports you need to look at the deno.json file and deno.lock file. They also added Deno Workspaces (monorepos) which adds more complexity. This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScrip…

Thanks for the reply. I don't understand what a TypeScript version bump has to do with import statements, though.

If you can’t resolve imports to source files then no static analysis tools will work. So, it has to be plugged into the compiler somehow.
Post reply on HN