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

171–180 of 321 posts

Re: TypeScript 7

#171

Post by steve_adams_86 »

hungryhobbit wrote: post #152
steve_adams_86 wrote: post #27

Earlier quoted context omitted.

I worked with people who would consider themselves serious, and are still in the industry and doing fine. A few have certainly gone on to be more prominent and get paid a lot more than I am—not that it's a perfect measure of seriousness. In the early days they would often say things like "but we have prop types, why use TypeScript", "why not use JSDoc" (this made no sense at the time), or "it's an exercise in needles…

Serious developers can make a serious argument that you can get quality production-level code with other ways besides explicit enforced type systems (eg. that if you have good enough test coverage such explicit type systems are a redundant waste of time). Obviously "production quality" varies greatly from shop to shop, but I think there's more legitimacy to the idea than you're giving it.

I didn't mean to paint with such a broad stroke, there. I've worked with people who are capable of writing exceptional software without type systems or other abstractions. I'm not that smart, though. I need a lot of guard rails to keep myself from doing stupid things. I was speaking more generally about people who didn't produce exceptional code yet still weren't open to means of improving their work if it meant having to open their minds to new ways of working.

This is totally fine sometimes though, because like you say, there are shops where this type of execution is suitable. It's why vibe coding is actually okay in many cases; it's not a lot different from what it replaces in these cases. There are a lot of situations where this is the bar, it produces enough utility an value, and that's great.

Re: TypeScript 7

#172

Post by ameliaquining »

dprkh wrote: post #59
horsawlarway wrote: post #50

Earlier quoted context omitted.

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

> as does python, which had a reputation for decades as THE language to use to teach new folks to code I am very perplexed by this. I am going through Neetcode's DSA course where he explains what RAM and arrays are, but then he goes on to say something like "but since we are going to use Python, none of this applies." Personally, I learned the most about how software really works from reading The Rust Programming Lan…

Learning the basics of programming is hard enough without also having to learn all those low-level details at the same time.

Re: TypeScript 7

#173

Post by ameliaquining »

TedDoesntTalk wrote: post #52
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.

Java has a lesson of what can go wrong with types, just as parent says. That example is dates and times. So many types… And before Java finally settled on what we have today, we had 3rd-party libraries like jodatime that tried to fix it. I guess it’s in a good state today, but it took a LocalDateTime.MAX to get there. I mean an Instant.MAX. No, I mean an OffsetDateTime.MAX. No, I mean new Date(Long.MAX_VALUE). Oh wai…

How would dynamic typing have helped with this? Presumably all those different classes would still exist and create fragmentation and compatibility problems; they'd just surface at runtime instead of compile time.

Re: TypeScript 7

#174

Post by drschwabe »

austinthetaco wrote: post #62

I'm still not sold on typescript. I've used it off and on professionally for years and it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you…

Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase.

Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically).

I personally don't have a need for TS which introduces an extra build step, extra ritual when defining functions, and no performance benefit over vanilla JS. If I want stricter coding pattern with performance benefits I will use C/C++ for the job instead.

Re: TypeScript 7

#175

Post by spartanatreyu »

ricardobeat wrote: post #132
hackerbrother wrote: post #122

Earlier quoted context omitted.

Do you think Bun's migration was irresponsible?

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.

> this TS migration started long before AI was able to help

Yes, but that doesn't mean it wasn't also "helped" along by AI.

See:

1. https://github.com/microsoft/typescript-go/pull/1387

2. https://github.com/microsoft/typescript-go/pull/2978

3. https://github.com/microsoft/typescript-go/pull/1138

4. etc...

Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.

---

The initial port was automated, then devs got in there, then LLMs got in there.

Re: TypeScript 7

#176

Post by ameliaquining »

skybrian wrote: post #102
MoonWalk wrote: post #90

Earlier quoted context omitted.

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?

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…

They actually have partial unstable TypeScript 7 support already. Internal documentation of how it works: https://github.com/denoland/deno/blob/main/cli/tsc/README.md...

Re: TypeScript 7

#177

Post by ameliaquining »

drschwabe wrote: post #174
austinthetaco wrote: post #62

I'm still not sold on typescript. I've used it off and on professionally for years and it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you…

Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase. Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically). I personally don't…

Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.

TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.

Re: TypeScript 7

#178

Post by ameliaquining »

kstrauser wrote: post #111
_flux wrote: post #89

Earlier quoted context omitted.

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…

That's fair, and I don't claim that I have the canonically correct answers. My broader claim is that I don't think I've ever heard someone say ugh, I despise that my bucket of bytes has an associated type! The real discussions weren't against types, but against various type disciplines. For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough…

I think it's pretty widely recognized these days that type inference for local variables is a good idea. Most major languages that didn't previously have it have since added it.

Re: TypeScript 7

#179

Post by nsonha »

kstrauser wrote: post #42
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 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…

> static, explicit typing

the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.

Re: TypeScript 7

#180

Post by fatata123 »

kstrauser wrote: post #42
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 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…

[dead]
Post reply on HN