This was a very strange story to see, because my life is almost a mirror image of the author's. Except my harebrained ORM-powered RPC message-queue rest-was-to

This was a very strange story to see, because my life is almost a mirror image of the author's. Except my harebrained ORM-powered RPC message-queue rest-was-too-slow experiment is working so far. Consider this a counterstory. The author lists two problems with the old system: code re-use and speed. But he doesn't really say how the solution is going to improve on the status quo, other than just by throwing programmers at the problem and hoping they improve on REST. Now maybe they had clear solutions and maybe they didn't--but the post doesn't say. I sympathize with the author's problems. But I also started with specific clarity about the problems and strong solutions about how in practice to improve. For example, the speed problem for my use case was very specifically that latency was too high. Latency was too high specifically because of fast-lived connections, the SSL handshake, and TCP overhead. So I designed a system very specifically around long-lived connections, a non-SSL based crypto layer, and UDP. It's a full order of magnitude faster; it actually changes the way you use network calls because they are so cheap now. As time has gone on I have extended the speed improvements, but it was way better than the status quo on day one. Similarly for code reuse, I had a very narrow set of problems surrounding reusing across client/server only very specific parts of very specific classes. As a result, rare is the change that requires moving client and server in lockstep. I don't think I did it in the month of February. And the productivity gain was great from day one. I am the first to admit that I've had some bugs in the complicated pipeline that require Deep Magic to comprehend. I have one or two open right now. But, if you have a 10x runtime improvement and a 3x development improvement, spending a day or two learning the ins and outs of Deep Magic is not the worst thing you can do. I think the moral to this story, if there is one, is don't fly by the seat of your pants. Don't write a system that is faster, write one that is exactly 92.56% faster by the application of two specific techniques. Don't write an RPC system that eliminates the barriers for sharing arbitrary code, write an RPC system that eliminates two particular barriers for classes that meet three known requirements that most people in the organization are annoyed about. If you don't know where you're going, you will never find out if you get there.