Live data from Hacker News

TypeScript 7

devblogs.microsoft.com

81–90 of 321 posts

Re: TypeScript 7

#81

Earlier quoted context omitted.

> I don't recall anyone disliking types > 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. hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?

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 definition at all.

Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior.

In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.

Re: TypeScript 7

#82
post #79

Earlier quoted context omitted.

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

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.

Re: TypeScript 7

#83
post #23

Earlier quoted context omitted.

dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

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

these painpoints seem moot in a world where AI agents are writing all the code.

Re: TypeScript 7

#85
post #9

Earlier quoted context omitted.

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

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.

Re: TypeScript 7

#86

For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?

It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.

Re: TypeScript 7

#87

Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?

For one, you’re not using TypeScript server-side. Whatever execution engine you are using is executing transpiled or JavaScript.

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.

Re: TypeScript 7

#89

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

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.

Re: TypeScript 7

#90

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.

I was wondering how this kind of change makes its way into environments like Deno. I'm building a project on Deno too.

As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?

Post reply on HN