If you're using @AtomEditor without https://nuclide.io and @flowtype, you're doing it wrong.
$ apm install nuclide
go
-
-
My impression is that TS favors ease of integration over strictness, aka their goal isn't to catch em all
-
For me, the fact that TypeScript is written in TypeScript is huge. I don't want to have to learn OCaml to debug Flow.
-
from my experience from Babel: extremely few people can and will contribute to compiler-y things [1/2]
-
Optimizing core team productivity is what should be focused on, that is what will push things forward [2/2]
-
that being said, I don't know the full reasoning behind this decision. I assume it's in no small part about performance.
-
FB seems to like ocaml a lot (see haxe, Reason etc). That's sort of cool apart from bad windows support
-
I dunno. I was told I wasn't supposed to use ruby in tooling to support contribution.
-
in retrospect that advice was correct.
- 2 more replies
New conversation -
-
-
typescript's type system is not flexible enough for me. Flow has gotten so good recently it's basically no contest anymore.
-
which kinds of flexibility are you talking about?
-
Also. Typescript can't be used to define complex types such as this.pic.twitter.com/rBsPWbIIHN
-
Is this a Higher Kinded Type? What is it being used for here exactly? Hard to tell just by looking at it.
-
This is just the definition. It takes a nullable type and gives you a non-nullable type. used it for Array<?T>.filter(Boolean)
-
in TS, I do things like: function unwrap<T>(v: Option<T>): T { if (v === null) throw new Error("null!"); else return v; }
-
for context: type Option<T> = T | null; type Maybe<T> = Option<T> | undefined;
-
That works for normal functions. Doesn’t work for methods like Array.filter
- 22 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

Just kidding, we know you write perfect code 