Goliath is not only relatively slow, it limits you to using libraries which have both an EventMachine implementation and an em-synchrony-style Fibered wrapper around them, which is basically a scant fraction of the total Ruby libraries available. This is pretty silly.

It might be worth noting that Grape is Rack based and will work very well alongside Rails or standalone on top of Rack (sample in https://github.com/dblock/grape-on-rack).

Yeah just async HTTP/TCP, databases, and system commands. Not anything anyone really uses

There is certainly not an EventMachine counterpart for every Ruby library available today. Furthermore, the EventMachine versions of most libraries are second class citizens compared to the synchronous versions of these libraries.

Goliath/em-synchrony make the situation even worse: now not only do you have to have an EventMachine version of a library (which is already probably less featureful and more poorly maintained than the synchronous version), you need a version of that EventMachine library which has been wrapped with Fibers. This means your pool of available libraries is even smaller and poorly maintained than what was available with EventMachine, let alone what's available with synchronous libraries. And all of this is to get you an API which resembles what the synchronous libraries would've given you in the first place.

Rails(-API) is designed to work with that rich ecosystem of well-maintained synchronous libraries. Due to its design, Goliath can't work with them.

So the question is: why would you forego the synchronous library ecosystem in Ruby to get "fake" synchronous libraries that only work with libraries that are 1) built from the ground up against EventMachine 2) have been wrapped to look like normal synchronous libraries em-synchrony style?

To have a ruby HTTP server with async request handling and semi-readable code?