jeffmo

A few reasons why we decided to build Flow

tldr: Flow is built to find a lot more kinds of bugs than what TypeScript is built for.

Flow avoids as much gratuitous unsoundness as possible in order to find more bugs: It never infers any, it models variance for objects/functions/type parameters soundly (this is critical), it minimizes type precision loss, it has sound support for various dynamic features with inference (Function.prototype.bind()/Function.prototype.call()/Object.assign()/etc), etc.

Flow infers and understands more kinds of types with fewer annotations. Extensive inference was important to us for easing the process of converting untyped code without missing errors as much as possible. It also helps reduce boilerplate when writing new, typed code. You get to decide if and when you want to express types in your code (with type annotations), but Flow will pick things up from there without much worry of losing type info.

Flow is built on top of a more general level of code understandi

OlegIlyenko

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

• query
• mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

jedisct1

#include "tweetnacl.h"

#define FOR(i,n) for (i = 0;i < n;++i)
#define sv static void

typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
typedef long long i64;
typedef i64 gf[16];