[erlang-questions] your first choice?

[e@REDACTED]

>> The crux of my argument is based upon the prior choice of features. First, you need prior knowledge of the framework itself. You need to know its performance model: what is fast and what is slow. You need to know the internal architecture. Otherwise, you are probably worse off than just writing the code. A network effect is apparent: the more you work in a framework, the more accumulated knowledge you have and the faster can you build new stuff. The 10th Rails project is easier to write than the 1st. Second, your problem has to match the frameworks framing, in the sense that the problem space you are facing matches somewhat well with that of the framework. As an example, it is hard to take the MVC pattern and fit into an Event Sourcing/CQRS model. Of course you could learn a new framework, but this requires prior knowledge as well.
>
> You actually may not need to know the framework that intimately.

This is a common problem of all "frameworks":
they all claim "no need to know them intimately" and they all in fact 
require that knowledge.

unlike many other "raw" tools.

frameworks massively fail at the task of abstraction -- knowing 
"specification" is never enough for a "framework".