Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.5

devblogs.microsoft.com

Post reply on HN
Print view View original

11–20 of 88 posts

Re: TypeScript 3.5

#11

Post by phiresky »

sli wrote: 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 non-syntax-error errors)

> I just cannot take a type system seriously when workarounds like that are needed.

Your problem really just seems to be that the type inference does not have magical powers. There is no other programming language that has union types as powerful as TypeScript (as in discriminating by whatever you want), but yeah when you do `return {x: 1, y: 2}` the compiler doesn't always know whether you mean to return an object where the type of x is `1` or where it is `number`. In some cases it could be better still, but doing this in general is just not possible.

Re: TypeScript 3.5

#12

Post by simplify »

panpanna wrote: post #8
simplify wrote: post #3

Earlier quoted context omitted.

> I just cannot take a type system seriously when workarounds like that are needed. Are you familiar with type theory and how easy it is for a type system to require too much work to be useful? Especially with conditional types. TypeScript has been doing a phenomenal job. For this particular use case, since version 3.4 you can write `'x' as const` which will work no matter how large your type is.

Speaking of which, is there any tutorials on type theory that targets developers instead of mathematicians?

Hindley-Milner is a solid place to start. Here's an introduction: http://akgupta.ca/blog/2013/05/14/so-you-still-dont-understa...

Re: TypeScript 3.5

#13

Post by PaulBGD_ »

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.

Re: TypeScript 3.5

#14

Post by jahewson »

sli wrote: 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…

TypeScript 3.4 has const assertions which solve the type widening issue you describe.

Re: TypeScript 3.5

#15

Post by pspeter3 »

PaulBGD_ wrote: post #13

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.

We do at Asana. I have not worked on it recently but I do believe that certain type signatures can have a large impact on build times.

Re: TypeScript 3.5

#16

Post by Dylan16807 »

phiresky wrote: post #11
sli wrote: 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…

This doesn't need magic powers. All you have to do is treat literal values inside type descriptions differently.

Re: TypeScript 3.5

#17

Post by TimTheTinker »

PaulBGD_ wrote: post #13

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.

Have you ruled out node and disk access time? If 30-file builds are taking 3s I suspect a sizable chunk of that is overhead (i.e. I'd expect the same from node-sass on 30 .scss files).

Re: TypeScript 3.5

#18

Post by phiresky »

Dylan16807 wrote: post #16
phiresky wrote: post #11

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…

This doesn't need magic powers. All you have to do is treat literal values inside type descriptions differently.

Inside of type descriptions, literal values are always treated as literals. The problem only appears when you declare a variable _without_ an explicit type like `const foo = {k: 'x'}`, which the compiler then infers to be of type `foo: {k: string}` and not `foo: {k: 'x'}`.

Both of these are valid inferences, and it's impossible to know which one the user wants in the general case, which is why you have to explicitly say `const foo = {k: 'x' as const}`.

Re: TypeScript 3.5

#19

Post by PaulBGD_ »

TimTheTinker wrote: post #17
PaulBGD_ wrote: post #13

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.

Have you ruled out node and disk access time? If 30-file builds are taking 3s I suspect a sizable chunk of that is overhead (i.e. I'd expect the same from node-sass on 30 .scss files).

Nope, strace reports 0.03s for all calls and about 0.02s of that is for filesystem stuff.

Re: TypeScript 3.5

#20

Post by wereHamster »

KenanSulayman wrote: post #10
sli wrote: 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…

I second that, to a degree. I write mostly TypeScript and Rust these days and it still behaves unexpectedly sometimes. Example: for a service we wanted to port Rusts’ Result. https://gist.github.com/KenanSulayman/34a40daa3ebbd1e1bdf7c7... Notice the ‘as any’ and ‘_T!: T;’ et al. hacks to make it work. Other than that it’s completely a one to one port from the Rust core implementation.

Because you're trying to manually optimize code, which is kindof like saying 'I konw what I'm doing so TypeScript please shut up'. Take for example the `map_err` function of the `Ok` class. The function returns a different `Result`, but you're using the `… as any` trick to shut up the compiler. The correct implementation would be:

    map_err(fn: (arg: E) => U): Result {
        return new Ok(this.value)
    }
I see why you're not doing that, because that allocates a new object, and that might seem bad. Even the implementation in Rust 'allocates' a new object, but then it relies on the rust compiler to optimize that out. Here's the relevant code:

    pub fn map_err F>(self, op: O) -> Result {
        match self {
            Ok(t) => Ok(t),
            Err(e) => Err(op(e))
        }
    }
See the `Ok(t) => Ok(t)` line? That's the same as `return new Ok(…)` in the TypeScript code. Unfortunately TypeScript is not an optimizing compiler, so it's less powerful than rust. You can either use tricks (`… as any`) and give up type safety or be truthful at the expense of performance.
Post reply on HN