Live data from Hacker News

TypeScript 7

devblogs.microsoft.com

111–120 of 321 posts

Re: TypeScript 7

#111
post #89

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…

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 to figure out what I mean, in the absence of ambiguity. Like imagine this C code:

  int main() {
      int i = 23;
      auto j = i;
      printf("i = %d, j = %d\n", i, j);
  }
There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can:

  fn foo1() -> i8 {
      23
  }
  
  fn foo2() -> String {
      "foo2".into()
  }
  
  fn main() {
      let f1 = foo1();
      let f2 = foo2();
      let f3 = f1 + f2;
      println!("Hello, world!");
  }
Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.

I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.

FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.

Re: TypeScript 7

#112
post #104
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 would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.

Re: TypeScript 7

#113

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

Because you can share types and even modules with your frontend project? Because for applications that aren't CPU-intensive it makes almost no difference? Because you are familiar with it and like it? Because of the humongous amount of libraries?

Re: TypeScript 7

#114
post #95
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.

Ish.

SBCL aggressively infers types wherever possible. It can do dynamic typing with tags of course. You can also write it with 100% static types.

Dynamic typing isn't a defining feature of Lisp style languages (even GC isn't necessary). Some historic Lisps and modern ones are 100% statically typed.

Re: TypeScript 7

#115

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.

Type systems just used to be bad. Anything that forces you to use a class hierarchy to represent an "OR" type (sum types) is painful to work with. Modern languages like TypeScript / Rust / Swift / Kotlin that have sum types are dramatically much nicer.

Re: TypeScript 7

#116

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

If you’re continuing to use the previous version in CI, there’s no reason to not use this locally. It’s a tremendous speed upgrade.

The reason to not use it locally is false negatives or false positives compared to your CI version. Your local tsc will not match the results of your CI tsc.

Re: TypeScript 7

#117

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

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.

Re: TypeScript 7

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

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 completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't.

> Python's strong typing mostly boils down to some operator rejecting mixed types.

Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.

Re: TypeScript 7

#120
post #104
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…

Okay, so I'm not crazy for thinking that declaring an empty, typed array as `const` and then writing/pushing to it is confusing/feels wrong.

I didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way.

It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;)

Post reply on HN