> And async/await is not solving anything because 
    > your definitions of fuctions will still need 
    > callbacks/promises under the hood anyway

It doesn't need to factor out every .then() or callback from your codebase to be incredibly useful or to fulfill its purpose.

Either option sounds full of compatibility / maintainability headaches, so how does Node get from its current state of callback hell out the box to async / await?

goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node.

From what I remember there was no plans to change that (based on discussion from couple of months ago by node members on github).

> Either option sounds full of compatibility / maintainability headaches

It is.

> goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node.

Of course it's not about turning code into sync one, it's about coding style to look like it would be a sync one. But in case of Go it was created with this as main language concept, everything was designed around it, scheduling, user space lightweight stacks for gorutines etc.

async functions using promises and generators under the hood is a good thing because it allows easy usage between the two forms.

A Go like model, with lightweight or real threads and no need for callbacks or promises will also need new synchronization mechnanisms in order to handle preemption and waiting which are currently not in scope of javascript, e.g. mutexes, condition variables, etc.