Even if you do manage to hack it in to something that wasn't designed with it in mind, it's always hacky, quirky, and unreliable, and you never quite know whether you're looking at a bug in your own code or in the state management hackery.
It isn't impossible. You are technically correct. But it's certainly taking impossible out for drinks, followed by long strolls on the beach, and a lot of meaningful staring.
Please do! Genuinely curious what you don't like about it.
That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around.
You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.
While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.
Perhaps ironically, when I worked on the iTunes Store (which is mostly all HTML and JavaScript) there was hardly a week went by that new code didn't get pushed (mostly bug fixes and under-the-hood updates). Yet Apple only really announced new iTunes Store features several times a year. So, one would hope they understand the need for continuously updating a complex piece of software, versus shipping major pieces of new functionality.
As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny.
Have a look at Flutter and Xamarin.
Flutter looks very promising btw, I probably can't use it yet though for the same reasons as Matcha, which is my current project depends on too many external libraries (for which React Native and the larger JavaScript community has been great).
1) Ability to quickly see changes in the simulator as you're modifying code (one of the main reasons I went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second).
2) Pushing new updates remotely, without having to resubmit your app. Would Go being statically compiled, mean we can't ship bits of executable code for minor updates / bug fixes as we see fit?
3) Debugging is really nice on RN, because you get to leverage awesome JS debugging environments like Chrome DevTools. While I've not yet had a need for a fancy debugger with Go, I could see that as a big sticking point for teams trying to choose.
Nonetheless, really applaud this effort so far, and look forward to seeing more. Go's concept of goroutines seems much better suited to UI event handling, then stringing together a ton of promises and callbacks. And don't even get me started on the async keyword...