> One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution.

Huh? I think you're misunderstanding how these functions work. You can't call an async function from a normal function and have it block the normal function. You specifically have to await the Promise returned by any async function.

> You specifically have to await the Promise returned by any async function

I just wanted to add (may help others): And you can only do that from within an async context (currently just the body of an async function).

Background: I started using async/await in my code a few weeks ago.

> I have one major misgiving about async-await - the regression in needing to do a try-catch if one isn't isn't a test situation. This is a terrible syntax to have to write to handle this.

If you don't like try/catch, you can still do:

    await getPromise().catch(err => {/* handle error */ })

Personally, I don't find the try/catch syntax that awful and it'll get better with do expressions[0], e.g.:

    const username = do {
      try { await getUsername() }
      catch (err) { 'unknown-username' }
    }

One common misconception is that async/await forces you to put everything inside a try/catch block which isn't the case. Errors get bubbled as with regular promises and you only need a try/catch block wherever you previously had a `.catch` (or you can keep the `.catch` as mentioned above if you prefer that syntax).

> One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution.

I'm not sure what you mean by that but you still have to explicitly use the "async" keyword for any function that uses "await". And function calls that are not prefixed with "await" will not block just like before. In fact, in an async/await codebase, you can more easily tell which functions are async because they'll have "async" in front of them (unlike errback/promise code which would require you to read the body of the function).

> Minus the awful try-catch, I'm not necessarily against async-await being the norm, but its broad effects on how async code will be written should be recognized, especially considering that it doesn't solve a fundamental issue like something like observables do.

Yes, it's basically just syntax sugar for promises but it does remove a lot of boilerplate code and is easier for JavaScript engines to optimise.

[0] http://wiki.ecmascript.org/doku.php?id=strawman:do_expressio...

I view the use of try-catch as actually strictly an improvement... Before you had either 2-argument promise.then(...) or promise.catch(...), which were effectively the same as a try-catch (and in most promise libraries .then and .catch DID use try-catch under the hood), except they were now duplicated syntax for doing the same thing (handling exceptional cases).

More likely you're arguing people shouldn't use 'exceptional situation' error handling as often as they do... but that's a separate argument. I think going from 2-3 syntaxes for the same thing to 1 syntax is strictly an improvement, especially since huge amounts of promise code silently swallow errors when people don't properly chain promises or handle the .catch case.

> and in most promise libraries .then and .catch DID use try-catch under the hood

To catch thrown errors, not to implement the behaviour of transforming rejected promises.

You could always do something like:

   const maybe = await fetch(url).catch(err => err);

But, I can understand that being a bit icky for some... but in a few cases it could make sense and is pretty concise:

   const hits = await cache.incr(key).catch(err => 0);

you don't have to you can await on settle() then deal with it in whichever way suits you