Live data from Hacker News

TypeScript 3.5

devblogs.microsoft.com

51–60 of 88 posts

Re: TypeScript 3.5

#51
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

> in many cases being unable to import a JS library in that doesn't include typedefs Make sure you have "allowJs": true in your tsconfig.json. Otherwise, you'll have to create a minimal file with `declare module "xyz";` > I fail to see how TS can be considered a superset of JS You have to interpret all TS "errors" as warnings for that to be true (which they mostly are considering tsc still emits code regardless of no…

> There is no other programming language that has union types as powerful as TypeScript

I suggest looking into Idris and other languages with dependent types. Nothing against typescript, but it’s not even close.

Re: TypeScript 3.5

#52
The 2 big things missing on typescript:

1) Operator overloading

2) Runtime type checking of JSON payloads (on dev env at least)

Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2

And the most common error that it should help catch during development is that you get a JSON and you cast it but it means nothing cause on runtime the JSON can be something completely different and nothing breaks until is somewhere else hard to debug, I get that Microsoft don't want to add runtime overhead but it should be possible at least on development mode.

Re: TypeScript 3.5

#53
post #49
post #23

Earlier quoted context omitted.

I can't downvote you but I want to point out that the only thing you accomplish with such a comment is coming off as ignorant and bitter. I have no idea why on Earth you think the type system is broken. Objectively, it simply isn't, obviously, but I'd love to see you trip over your own feet trying to argue that it is. Moreover, it's honestly remarkable how they've managed to retrofit such an amazing type system on to…

I don't know if 3.5 fixes this, but here's an example from 3.4 function messUpTheArray(arr: Array ): void { arr.push(3); } const strings: Array = ['foo', 'bar']; messUpTheArray(strings); const s: string = strings[2]; console.log(s.toLowerCase()) You obviously can't push a number into an Array , yet typescript allows it. For my money, ReasonML is a better solution for type issues (hindley-milner types are awesome).

Interesting, though it does flag the push() as an error if you use "Array | Array" as the argument type.

It almost seems like some sort of co/contravariance issue?

A function that reads from an Array should be able to accept either an Array or an Array (or Array), but a function that mutates it should only be able to accept Array?

Re: TypeScript 3.5

#54

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

Yes, the Typescript compiler is slow. I tend to notice all compilers as feeling "too slow". I think the cause is that we all have wayyyy too much code. Not that we write, but when we use a library, that uses 10 libraries, that each use 10 libraries. Now you have a million lines of code, and all you wanted to do was print hello world. The compiler doesn't know until it's read all of that that you aren't using any of i…

what library do you use to print hello world?

Re: TypeScript 3.5

#55

Earlier quoted context omitted.

> in many cases being unable to import a JS library in that doesn't include typedefs Make sure you have "allowJs": true in your tsconfig.json. Otherwise, you'll have to create a minimal file with `declare module "xyz";` > I fail to see how TS can be considered a superset of JS You have to interpret all TS "errors" as warnings for that to be true (which they mostly are considering tsc still emits code regardless of no…

> There is no other programming language that has union types as powerful as TypeScript I suggest looking into Idris and other languages with dependent types. Nothing against typescript, but it’s not even close.

Idris doesn't have anonymous sum types, nor does Coq or Lean. Which language were you thinking of?

Re: TypeScript 3.5

#56

The 2 big things missing on typescript: 1) Operator overloading 2) Runtime type checking of JSON payloads (on dev env at least) Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2 And the most common error that it should help catch during development is that you get a JSON and you cast it but it means no…

> 1) Operator overloading

Please, please, please, no.

Re: TypeScript 3.5

#57

The 2 big things missing on typescript: 1) Operator overloading 2) Runtime type checking of JSON payloads (on dev env at least) Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2 And the most common error that it should help catch during development is that you get a JSON and you cast it but it means no…

> 1) Operator overloading Please, please, please, no.

You know it would be completely transparent right? Just gets transpiled into .__add__(obj)

Re: TypeScript 3.5

#58

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

TS 3.4 has known performance regressions. 3.5 helps, but it's still slower than 3.3.

I don't really notice it, though, because I've got `tsc --watch` running in a terminal continuously as I edit code.

When tsc sees edits, recompilation competes in tens of ms. It's really quick.

Re: TypeScript 3.5

#59

It sounds like type inference for object literals is coming along, even if there a few quibbles about some of the defaults on literals mentioned here. Did they ever get a solution in place for partial function application (e.g. - as for Ramda.js)? When this gets to the point where the only place I have to define explicit types is for JSON data read from the network, I’ll consider using it. I know I’m in the minority,…

I think it's best to require type annotations at interface boundaries, but not within implementations. That way, changes to the interface are obvious, but excessive verbosity within a module is limited.

Re: TypeScript 3.5

#60

The 2 big things missing on typescript: 1) Operator overloading 2) Runtime type checking of JSON payloads (on dev env at least) Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2 And the most common error that it should help catch during development is that you get a JSON and you cast it but it means no…

I use https://github.com/gcanti/io-ts for the runtime checking. It is similar to tcomb (same author)!

You can even define the type via io-ts and then make a TypeScript interface out of it!

Given this, and the other libraries that do something similar, I am not sure why Microsoft needs to add it to the language.

Post reply on HN