I don't understand much of what you've written. Perhaps you can elaborate? Specifically:
> It's also not about scaling at all.
It's about handling many simultaneous connections. How is this not a specific type of scaling, and one that is relevant to many web sites?
> a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
What does this mean beyond the fact that data dependencies limit parallelism?
> Instead of being forced to use a compiler-assisted construct
For comprehensions in Scala are syntax for the flatMap and map functions. You're not forced to use them, and for comprehensions work with any monad.
> Deref'ing (@) a promise over and over is totally okay.
Mapping a promise (the Scala equivalent) over and over is totally ok.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
What does the IO model of the JVM have to do with Scala futures? Blocking IO operations are blocking, whatever language you use. There are three ways around this:
1. Use nonblocking IO
2. Use bytecode manipulation to transform blocking to nonblocking IO
3. Use a separate thread pool for blocking IO operations.
> It's also not about scaling at all.
It's about handling many simultaneous connections. How is this not a specific type of scaling, and one that is relevant to many web sites?
> a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
What does this mean beyond the fact that data dependencies limit parallelism?
> Instead of being forced to use a compiler-assisted construct
For comprehensions in Scala are syntax for the flatMap and map functions. You're not forced to use them, and for comprehensions work with any monad.
> Deref'ing (@) a promise over and over is totally okay.
Mapping a promise (the Scala equivalent) over and over is totally ok.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
What does the IO model of the JVM have to do with Scala futures? Blocking IO operations are blocking, whatever language you use. There are three ways around this:
1. Use nonblocking IO
2. Use bytecode manipulation to transform blocking to nonblocking IO
3. Use a separate thread pool for blocking IO operations.
1 and 3 are the typical solutions in Scala.