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

101–110 of 321 posts

Re: TypeScript 7

#101

Post by BoingBoomTschak »

wk_end wrote: post #95
bbg2401 wrote: post #56

Earlier quoted context omitted.

> Remember when people would argue about how types weren't worth the effort? > if nothing else for how it's been able to popularize types. This is such an odd, javascript dev take.

It's maybe a bit of a startup-world, HN-blinkered assessment...but that's where we're talking, isn't it? Even before JS became the language for everything, there was a good chunk of time - maybe between 2005 and 2015? - when Python and Ruby were dominant in this environment, and this dismissive attitude towards static typechecking was similarly dominant. Of course in the enterprise space everyone was using Java, and…

> Lisp is dynamically typed

"Lisp" isn't a single language. Arguably the language people speak about when they say Lisp without qualifier, ANSI CL, allows conforming implementations (e.g. SBCL) to offer gradual typing, not just heuristics.

Re: TypeScript 7

#102

Post by skybrian »

MoonWalk wrote: post #90
NetOpWibby wrote: post #34

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?

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 TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it.

I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.

Re: TypeScript 7

#103

Post by mamcx »

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.

Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!

P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.

Once you see what good application of types look like, is far better sell!

Re: TypeScript 7

#104

Post by dtech »

jt2190 wrote: post #93
_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…

> Strongly typed and weakly typed do not seem to have good definitions. Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?

There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed.

In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them.

Example:

   const dogs: Dog[] = []
   // A sound type system would error here,
   // but there's too many useful cases where you want to do this
   const animals: Animal[] = dogs 
   animals.push(new Cat())
   animals[0].bark() // runtime TypeError here

Re: TypeScript 7

#105

Post by m_ke »

kodama-lens wrote: post #100
m_ke wrote: post #91

After running out of Fable credits in a day on my max plan I started looking around for ways to trim down my token usage and came to the realization that all of the type spaghetti that opus wrote is probably eating up like 50-70% of my tokens. A clean django project is probably 3-4x less code than the equivalent TS based service. It made me consider dropping strict mode and defaulting to js for most simple things.

In a world where code generation is cheap, why use untyped languages? Types add confidence, stricter interfaces, and most likely a better runtime performance.

With agentic coding the costs of tokens compound with each message / tool call and etc. Having to load in and update large files makes things slower and way more expensive.

Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-d...

simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs.

PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).

Re: TypeScript 7

#106

Post by tgv »

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…

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.

Re: TypeScript 7

#107

Post by jakubmazanec »

austinthetaco wrote: post #69
jakubmazanec wrote: post #67

Earlier quoted context omitted.

> I am still of the opinion that well organized and named JS is all that anyone needs You probably didn't work on any medium or large codebase and didn't have to do a refactor. > 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 What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.

You really should just not assume things about people with no reason other than "they dont like the things i like so therefor they must not be experienced". I've worked on plenty of very very large codebases with large teams. > What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created. did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and…

> 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 have enough experience.

> it was created by microsoft

It was created at Microsft, but it was crated by Anders Hejlsberg who, I'm pretty sure, didn't want to just "create a safehaven to C# and java devs", he was actually solving real problems with JS development, completely orthogonal. You can argue that TS's first syntax was very C/C# inspired, and that Anders also created C#, but that's not what OP meant (or at least how it read).

Re: TypeScript 7

#108

Post by bennettpompi1 »

dtech wrote: post #104
jt2190 wrote: post #93

Earlier quoted context omitted.

> Strongly typed and weakly typed do not seem to have good definitions. Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?

There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed. In Typescript this is by design. The most obvious is array variance. Typescript ma…

I may be missing something, but your example doesn't typecheck?

  class Animal { }
  class Dog extends Animal{
    bark(){return 1}
  }
  class Cat extends Animal{
    bark(){return 1}
  }
  const dogs: Dog[] = []
  const animals: Animal[] = dogs
  animals.push(new Cat())
  animals[0].bark()

Re: TypeScript 7

#109

Post by overfeed »

egorfine wrote: post #82
hvb2 wrote: post #79

Earlier quoted context omitted.

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.

eons ago, I migrated a frontend to Typescript and caught a lot of type-related bugs[1]. It was a 5kLoC, fast-moving productized prototype written by a team of 5. I won't ever do dynamic-typed plain Javascript in a team ever again, type-checker is superior to human code-reviews when it comes to catching potential bugs. Then again I prefer codebase stability of clever code or "expressiveness"

1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.

Re: TypeScript 7

#110

Post by overfeed »

aaronvg wrote: post #83
tiffanyh wrote: post #43

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…

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

That world will never be. Humans will always be writing some code, at least for as long as I live and breathe.
Post reply on HN