Live data from Hacker News

TypeScript 7

devblogs.microsoft.com

261–270 of 321 posts

Re: TypeScript 7

#261
post #106

Earlier quoted context omitted.

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

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.

Re: TypeScript 7

#262
post #106

Earlier quoted context omitted.

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…

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.

Strongly typed is not a well defined term.

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.

Re: TypeScript 7

#263

Earlier quoted context omitted.

> You really should just not assume things about people with no reason other than "they dont like the things i like That's not the reason for my comment. I truly don't understand how after so many years someone "isn't sold" on TypeScript. Sure, you don't have to use it if you don't want to, but if don't see how it's truly essential in current JS development, I don't know what else to assume, other than OP doesn't hav…

Its not essential. Good organization. Good functional configuration. Proper separation. Good variable naming. All of these things are what make it more than easy to work without type declaration. People have been working on huge code bases without types for a VERY long time with no issue, especially in functional paradigms.

> People have been working on huge code bases without types for a VERY long time with no issue

People have been successfully writing assembly, your argument is useless.

Re: TypeScript 7

#264
post #169

Earlier quoted context omitted.

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.

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.

Re: TypeScript 7

#265

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

I don't think it's reasonable to expect the TS team to hold back the release until the ecosystem has caught up.

Re: TypeScript 7

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

Re: TypeScript 7

#267

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.

What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.

Re: TypeScript 7

#268

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

https://news.ycombinator.com/item?id=48840113 seems to answer that question. I.e. an api for the compiler is being worked on.

Sure but typescript-language-server is different because it's also from MS.

Re: TypeScript 7

#269
post #256

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…

Also it cost $165K in tokens

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.

Re: TypeScript 7

#270
post #205

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.

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…

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.

Post reply on HN