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

31–40 of 88 posts

Re: TypeScript 3.5

#31

Post by phiresky »

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.

Your problem there seems to mostly be that you tried to directly port it without any modifications, and your code is actually incorrect in some places. For example, if you implemented Result as a single class that had a `if(this.is_ok()) ...; else ...` it would work fine without any type assertions or any anywhere.

As it is, Ok only depends on T and Err only depends on E, so why do you have them depend on both?

One problem is that TS does not want to merge unionized function signatures like this:

    map: ((fn: (arg: "yep") => U) => Ok) | ((fn: (arg: any) => U) => Result)
This can be mostly fixed by removing arguments that you don't need.

I couldn't figure out .map_or_else, but .map().or_else() works.

Admittedly, with this way you can get an output of Ok | Ok from some functions, but I don't know where that would be a problem (still fully type checked, you would just get the expected error further outside.

Here's a updated gist: https://gist.github.com/phiresky/621f8d8ed6eb00c9a0ddb47217e...

Re: TypeScript 3.5

#32

Post by phiresky »

Dylan16807 wrote: post #29
phiresky wrote: post #18

Earlier quoted context omitted.

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…

So the example of `false | 'x' | 'y' | undefined` turning into string is invalid? I feel like I'm missing something.

here's a full example. If you do this:

    function test(p: {k: false | 'x' | 'y' | undefined}) {
        // do stuff
    }
    const p = {k: 'x'} // inferred type: {k: string}
    //...
    test(p); // type error : Type 'string' is not assignable to type 'false | "x" | "y" | undefined'
The problem is that the type of p.k is inferred to `string` not `x`. The compiler can't know this is fine because you could call `foo(p)` in between the declaration and the `test` call, that mutates p.k.

If you add `as const` or an explicit type to p it is fine.

(I think this is what the GGP was referring to)

Re: TypeScript 3.5

#33

Post by [deleted] »

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.

[deleted]

Re: TypeScript 3.5

#34

Post by phiresky »

IceDane wrote: post #23
alttab wrote: post #5

Typescript 3.5: fixing the problems we introduced and providing workarounds for new features in a broken type system.

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…

> Objectively, it simply isn't, obviously

To be fair, TS has some pretty bad unsoundness problems, especially regarding co/contra variance in generics, and for example some annoying weirdness with number/string keys in objects. Still, the type system is one of the most amazing ones I know.

Re: TypeScript 3.5

#35

Post by Dylan16807 »

phiresky wrote: post #32
Dylan16807 wrote: post #29

Earlier quoted context omitted.

So the example of `false | 'x' | 'y' | undefined` turning into string is invalid? I feel like I'm missing something.

here's a full example. If you do this: function test(p: {k: false | 'x' | 'y' | undefined}) { // do stuff } const p = {k: 'x'} // inferred type: {k: string} //... test(p); // type error : Type 'string' is not assignable to type 'false | "x" | "y" | undefined' The problem is that the type of p.k is inferred to `string` not `x`. The compiler can't know this is fine because you could call `foo(p)` in between the declara…

Thanks!

Re: TypeScript 3.5

#36

Post by noir_lord »

phiresky wrote: post #34
IceDane wrote: 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…

> Objectively, it simply isn't, obviously To be fair, TS has some pretty bad unsoundness problems, especially regarding co/contra variance in generics, and for example some annoying weirdness with number/string keys in objects. Still, the type system is one of the most amazing ones I know.

Yeah but if you think about it they are putting a straight jacket on a madman while a committee organizes regular PCP shipments to said madman.

That they got it to work amazes me, that they got it to work well astounds me.

It's one of the few parts of my stack that I interact with every day I don't occasionally want to hunt down the creators of.

Re: TypeScript 3.5

#37

Post by [deleted] »

PaulBGD_ wrote: post #19
TimTheTinker wrote: post #17

Earlier quoted context omitted.

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.

[deleted]

Re: TypeScript 3.5

#38

Post by AgentME »

likeabbas wrote: post #21
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…

For the comment about not being able to use JS libs that don’t have typedefs, this is why I wish Facebook’s Flow was more popular. You can use as much or as little of typing as you want and don’t need to to write typedefs for every JavaScript lib you wish to use. It also had static code analysis that could infer types.

Flow won't infer types of arbitrary Javascript libraries. It will let you use them as untyped values, just like Typescript does when you set the allowJs option.

(I've used Flow for a long time. I'm starting to transition a large codebase from Flow to Typescript, and I'd highly recommend anyone to just start with Typescript rather than Flow. Flow's type inference isn't all that useful, and causes Flow to be magnitudes slower than Typescript. In a large codebase, it can take Flow tens of seconds to minutes to react to a code change and show you errors or auto-completions in your code after typing in an editor, compared to practically instantaneous updates with Typescript.)

Re: TypeScript 3.5

#39

Post by ElFitz »

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…

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

How about Swift and OCaml? ReasonML comes to mind too. Haven't tried actively comparing any of them though.

Re: TypeScript 3.5

#40

Post by jrockway »

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.

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 it. The solution is to depend on libraries more carefully.

As the go team says, a little copying is better than a little dependency. This is a motto that the npm community has NOT taken to heart. The cost is slow build times. (To be fair, the go community has not taken this to heart either.)

Post reply on HN