Hacker News Reader

Comment by iamaleksey | Hacker News Reader

REST, Thrift, AMQP + protobuffs.

http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/

Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible...

incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One (ASN.1), which predates XML, but didn't take off.

ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists.

And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift.

This is how I ended up with RabbitMQ and ASN.1.

Thanks. The long-term trajectory of programming tools seem to favour developer ease over raw efficiency, as computers get faster but programmers don't (though possibly this might change as Moore's Law diverts from speed increases to multi-core).

Therefore, XML became more popular than ASN.1. I think the successor to XML (and SOAP etc) will be more human-friendly than XML, rather than more efficient.

That's not to say that extremely efficient techniques don't have a place (they do) or they're not cool (they are).

I actually coded one of Facebook's coding puzzles (Battleship) using Thrift and was pleasantly surprised. It provides support for many languages and getting up and running was a snap. I hope it catches on.

Reply on news.ycombinator.com