Sort of, although I read it more as "I'm not interested in making Erlang performant because I wouldn't write anything that has to run fast in Erlang". But if I'm writing in Erlang I want to make it as performant as possible since it's doing something kind of important. E.g., RabbitMQ and Riak wouldn't be as cool as they are if it wasn't performant.
I also interpreted your post in the way that davelnewton did. I guess the thing to remember is that even the slowest systems can have both "high performance" and "low performance" ways of using them.
I guess, but in my experience optimization buys you maybe 2x if the code was written reasonably well. By using Erlang you leave 3x-30x on the table vs reasonably well written C, and it's often easier to write that C code than to optimize the heck out of code in a slower language which ends up being 3x-30x slower anyway. On the other hand Erlang is an excellent choice for distributed systems that are latency bound.
If you've decided that Erlang is the right system to use, isn't it good to know how to -when needed- design the fastest Erlang code possible?
The existence of another language that creates faster programs doesn't make the task of optimizing software written in the slower language irrelevant.
Make sense? :)
And, I mean, languages like Erlang make writing software to solve certain classes of problems far easier than if one were using straight C. What's more, Erlang lets you plug in code written in other languages, so you can keep the very logically tricky stuff in Erlang, and do the perf-critical stuff in -say- C.
I didn't say optimizing Erlang is irrelevant, just that for me a book about optimizing Erlang is less relevant than a book about writing distributed systems in Erlang.