
Evolution of the Heroku CLI: 2008-2017 - rayascott
https://blog.heroku.com/evolution-of-heroku-cli-2008-2017
======
Rapzid
I predict they will come to the conclusion that they backed the wrong horse
with Flow over TypeScript; v7 will be written in Scala or Scala.js .

There is the odd sense of randomness to the choices in all these CLI upgrades.
Can't quite put my finger on it. It brings to mind the saga of Wasabi.

~~~
z3t4
I think the idea with Flow is you just have JSDoc type annotations, so you get
strong typing without transpiration.

~~~
styfle
I believe TypeScript has the JSDoc feature as well, although it's much more
recent.

~~~
styfle
[https://code.visualstudio.com/Docs/languages/javascript#_typ...](https://code.visualstudio.com/Docs/languages/javascript#_type-
checking-and-quick-fixes-for-javascript-files)

------
petepete
Instead of using Promise.all, wouldn't an approach like this work?

    
    
        const a = taskA();
        const b = taskB();
        const c = taskC();
    
        const result = [await a, await b, await c];

~~~
itwy
These are not the same. Promise.all guarantees a is executed then b then c.

Your version guarantees the three are executed before moving forward. The
order may differ on each run.

~~~
exogen
FYI, Promise.all does not guarantee that. It doesn't orchestrate actually
running the Promises at all (this is impossible the way Promises work), just
that they're all resolved at the end, with _results_ in the same order they
were passed in.

~~~
itwy
What is the difference then?

~~~
hdhzy
None from the perspective of the consumer.

The implementation of Promise.all _could_ use one array for results and fill
it in any order as soon as any promise resolves while awaits will always
proceed in strict order (like a generator). But that's an implementation
detail that a JS programmer doesn't need to think about.

~~~
itwy
Thanks for the clarification.

------
z3t4
Instead of awaiting IO in CLI tools I just use the sync version

