Live data from Hacker News

Flowtype 0.30 adds support for Windows

flowtype.org

11–18 of 18 posts

Re: Flowtype 0.30 adds support for Windows

#11
post #5

Earlier quoted context omitted.

> conversion tool for package publishers I'm not sure I understand how that's different from just supporting TypeScript definitions. Couldn't the conversion tool just be built into Flow so that it works transparently for the user? Or are you saying human intervention is required? > Flow has a more sound type system Can you elaborate? What are the features of Flow that aren't present in TypeScript and would result in…

It's not a trivial task for either Flow or TypeScript to support definitions of one another. We've attempted to build a TS => Flow conversion tool, but it's much harder to go in that direction because you have less guarantees. You aren't going to find a lot of "features" that either one supports that the other does not. However, many of TypeScript's implementations of the same features are less strict even with all o…

It should be much easier to implement a "TS definition source files (.d.ts) => Flow" converter than generic "TS => Flow". The language in .d.ts is a small subset of TS. Are your explanations about Flow's strictness really applicable to this subset?

See https://github.com/Microsoft/TypeScript/blob/master/doc/spec...

> Here's an example that came up just last week: [...] (Note: This is not a bug in TypeScript, it's a design decision)

I believe this design decision isn't final, but again: what difference does this example make if we're talking just about type declarations?

Re: Flowtype 0.30 adds support for Windows

#12

Earlier quoted context omitted.

It's not a trivial task for either Flow or TypeScript to support definitions of one another. We've attempted to build a TS => Flow conversion tool, but it's much harder to go in that direction because you have less guarantees. You aren't going to find a lot of "features" that either one supports that the other does not. However, many of TypeScript's implementations of the same features are less strict even with all o…

It should be much easier to implement a "TS definition source files (.d.ts) => Flow" converter than generic "TS => Flow". The language in .d.ts is a small subset of TS. Are your explanations about Flow's strictness really applicable to this subset? See https://github.com/Microsoft/TypeScript/blob/master/doc/spec... > Here's an example that came up just last week: [...] (Note: This is not a bug in TypeScript, it's a d…

I had these same thoughts, but I decided to just drop it. The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team (perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy better and the type system was better-designed until recently, the TypeScript community and ecosystem trump any benefits of Flow at this point.

Re: Flowtype 0.30 adds support for Windows

#13

Am I correct in saying that the Hack and Flow typecheckers share a lot of code? If so, does this mean that Hack typechecking on Windows could be next?

Yep, you are correct! The hardest parts of getting Flow and Hack to build on Windows are solved. For Hack, there's probably a long tail of small issues before a Windows build can be released, though.

Is Hack on Windows something that you'd use? Or are you asking out of curiosity?

Re: Flowtype 0.30 adds support for Windows

#14
post #12

Earlier quoted context omitted.

It should be much easier to implement a "TS definition source files (.d.ts) => Flow" converter than generic "TS => Flow". The language in .d.ts is a small subset of TS. Are your explanations about Flow's strictness really applicable to this subset? See https://github.com/Microsoft/TypeScript/blob/master/doc/spec... > Here's an example that came up just last week: [...] (Note: This is not a bug in TypeScript, it's a d…

I had these same thoughts, but I decided to just drop it. The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team (perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy better and the type system was better-designed until recently, the TypeScript community and ecosystem trump any benefits of Flow at this point.

However that may be, I am really curious to see an example of an unconvertible type definition.

Re: Flowtype 0.30 adds support for Windows

#15
post #12

Earlier quoted context omitted.

I had these same thoughts, but I decided to just drop it. The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team (perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy better and the type system was better-designed until recently, the TypeScript community and ecosystem trump any benefits of Flow at this point.

However that may be, I am really curious to see an example of an unconvertible type definition.

As of the latest version of TypeScript, there aren't any anymore. There's a discussion in a TypeScript GitHub issue about it, but I can't find it now.

Re: Flowtype 0.30 adds support for Windows

#16

Am I correct in saying that the Hack and Flow typecheckers share a lot of code? If so, does this mean that Hack typechecking on Windows could be next?

Yep, you are correct! The hardest parts of getting Flow and Hack to build on Windows are solved. For Hack, there's probably a long tail of small issues before a Windows build can be released, though. Is Hack on Windows something that you'd use? Or are you asking out of curiosity?

It is. We have a large codebase we would like to migrate to Hack, but we also have a lot of developers who use Windows and the current experience with needing to boot a virtual machine just to check types doesn't really cut it.

Re: Flowtype 0.30 adds support for Windows

#17
post #12

Earlier quoted context omitted.

It should be much easier to implement a "TS definition source files (.d.ts) => Flow" converter than generic "TS => Flow". The language in .d.ts is a small subset of TS. Are your explanations about Flow's strictness really applicable to this subset? See https://github.com/Microsoft/TypeScript/blob/master/doc/spec... > Here's an example that came up just last week: [...] (Note: This is not a bug in TypeScript, it's a d…

I had these same thoughts, but I decided to just drop it. The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team (perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy better and the type system was better-designed until recently, the TypeScript community and ecosystem trump any benefits of Flow at this point.

> The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team

It makes me sad that you think this. The team cares very deeply about usability and adoption. We've committed to making it our sole focus for the current half. I was brought onto the team to focus on the external experience and adoption because of my experience working on Babel.

We're solving a very difficult problem space, and we're doing our best to do it right. Trust me that we're thinking about all the same things you are and finding ways to address them.

Also, I must say that I agree that the TypeScript has a massive lead in the community and ecosystem. It's just our opinion that we've set ourselves up to do even better, we're just now switching modes from making the type checker awesome to making the user experience awesome.

If you have any concerns about the experience we're happy to hear it. Having a rapid constant feedback loop is important.

Re: Flowtype 0.30 adds support for Windows

#18
post #12

Earlier quoted context omitted.

I had these same thoughts, but I decided to just drop it. The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team (perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy better and the type system was better-designed until recently, the TypeScript community and ecosystem trump any benefits of Flow at this point.

> The Flow team doesn't seem nearly as interested in usability/adoption as the TypeScript team It makes me sad that you think this. The team cares very deeply about usability and adoption. We've committed to making it our sole focus for the current half. I was brought onto the team to focus on the external experience and adoption because of my experience working on Babel. We're solving a very difficult problem space,…

James, I'd be glad if you answered my pretty simple and specific questions here: https://news.ycombinator.com/item?id=12209131
Post reply on HN