News for hackers. Stuff that matters.
Re:Yarn's Future – v2 and beyond by tonyhb on Thursday January 24, 2019 @12:06PM (#18990522)
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
Re:Yarn's Future – v2 and beyond by WorldMaker on Thursday January 24, 2019 @12:32PM (#18990798)
Things are quite different from the first few years. Typescript has largely converged with the capabilities of Flow as a type system, though from its "different direction". It's not entirely ML-ish algebraic types, but it's a usefully fair approximation that has a lot of pragmatic tools to get the job done. Similarly too, the type inferencing engine isn't a "proper" ML-ish one, but it's gotten very good at what it does, again to the point where things are starting to feel a lot more similar to Flow's support than ever. Especially because Typescript is getting a huge workout as the inferencing engine in VSCode, Atom, VS Proper (sometimes), and increasingly more IDEs even for raw JS projects with little to no type information.

Even if you don't believe in the old Unix adage that "worse is better", Typescript today isn't that demonstrably worse than Flow. Depending on your metrics, such as general availability of community-supported type information, Typescript in increasing ways better.

Re:Yarn's Future – v2 and beyond by noir_lord on Thursday January 24, 2019 @04:19PM (#18993071)
Anders (and the people he works with) has a track record of producing useful pragmatic tools/languages that help developers develop going back about 3 decades.

I've yet to find anything he's done/worked on that I don't like, one of my programming heroes actually.

Re:Yarn's Future – v2 and beyond by 4di on Thursday January 24, 2019 @03:52PM (#18992820)
I worked with Typescript for 2 years, then worked with Flow for 2 years and now I'm back on Typescript working for a big company.

I agree that Flow had better capabilities around soundness. But the tooling around Typescript really made me jealous, specifically in VSCode.

Near the end of working with Flow, Typescript was getting some cool capabilities like refactoring JSX for React apps.

Nowadays I can easily say that Typescript is a far better experience than Flow. There are updates every two months, adding some neat features that you might find in other languages.

Then you add in the power of surrounding tools and their ecosystems like TSLint and it really feels like a next-level coding experience where the tools start writing the mundane code for you, driven the core TS static analysis.

Re:Yarn's Future – v2 and beyond by wafflesraccoon on Thursday January 24, 2019 @05:28PM (#18993695)
I'd agree with everything you've said. Flow isn't bad but after working with TypeScript I could never go back. You're spot on with the tooling and ecosystem.
Re:Yarn's Future – v2 and beyond by ggregoire on Thursday January 24, 2019 @05:44PM (#18993814)
Also, TypeScript has a roadmap and when you report a bug, the devs actually reply. Flow doesn't have any of that.
Re:Yarn's Future – v2 and beyond by fooey on Thursday January 24, 2019 @09:05PM (#18994934)
and now TSLint is merging with ESLint so all that effort and rules duplication will be going away
Re:Yarn's Future – v2 and beyond by daveidol on Thursday January 24, 2019 @03:18PM (#18992503)
I don't think that holds anymore. Have you used both Flow and Typescript recently? Speaking from experience: I can't imagine anyone doing so and concluding that Typescript is the "worse technology" at this point.
Re:Yarn's Future – v2 and beyond by tonyhb on Thursday January 24, 2019 @06:44PM (#18994202)
Not recently. It's now on my TODO to plan a transition of our frontend projects to Typescript. Have been thinking about it since 2.9 when they finally introduced mapped types; before then we were using some of Flow's meta functionality to auto-type our reducers.
Re:Yarn's Future – v2 and beyond by danielnixon on Thursday January 24, 2019 @06:46PM (#18994206)
This[1] typechecks in Flow but not in TypeScript:

    /* @flow */

    interface HasIdentityFunction {
      id<A>(a: A): A
    }

    class Example implements HasIdentityFunction {
     id<A>(a: A): number {
       return 42;
     }
    }

    var x: string = (new Example(): HasIdentityFunction).id("hello")
[1] https://twitter.com/puffnfresh/status/1077072700609159168
Re:Yarn's Future – v2 and beyond by whatever_dude on Thursday January 24, 2019 @04:14PM (#18993023)
> This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues

Most of not all of the issues had with types have been solved.

Flow had some major tooling/developer comfort issues from day one and none of those are solved. Not to mention a really closed development roadmap (understandable perhaps, but nonetheless bad).

As a developer, I'm glad TypeScript won. I want more tool/compiler/language/etc makers to understand that the developer experience matters. If someone makes a tool that only works well under one very specific setup and ignores everyone else, that's just very limiting.

Re:Yarn's Future – v2 and beyond by Normal_gaussian on Thursday January 24, 2019 @12:30PM (#18990777)
This is certainly how I feel; there are large parts of my codebases that I don't think will convert well if I was to change, where we leveraged flow to great effect.

However I certainly take the point that flow has been developer hostile. When we have had issues it has been impossible to get a response (here is a demo, is this a bug or in the pipeline?).

Though flow is v0.91 and Typescript is 3.2, i don't know if i can really fault them that much?

I don't trust TS, they are too much 'move fast and break things'.

Re:Yarn's Future – v2 and beyond by WorldMaker on Thursday January 24, 2019 @12:39PM (#18990873)
Typescript has been moving fast, but they haven't broken that many things. The API and Language Server have changed obviously four times from a semver perspective, but in general the language itself has been extremely stable with great backwards compatibility, and most of the type system strictness additions are behind opt-in flags making upgrades usually as gentle as you prefer them to be (depending on your attitude to strict type checking).

(I had projects that started with TS < 1.0 and they all still parse and compile today, albeit with tons of lint warnings, particularly to use a better module system than AMD with pre-ES2015 TS imports, and all sorts of new type strictness options to turn on to make them all the more type safe.)