[morecoffee]

> Eh, I'd rather pay the cost of serialisation once and deserialisation once, and then access my data for as close to free as possible, rather than relying on a compiler to actually inline calls properly.

The thing is, as close to free as possible is surprisingly expensive. Protobuf's varint encoding is extremely branchy, and hurts performance in a datacenter environment (where bandwidth is free, and CPU is expensive).

> As pragmatic design choices go, Cap'n Proto's is a good one (although it violates the standard network byte order). Intel effectively won the CPU war, and we'll never be free of the little-endian plague.

Did they though? Arguably there are far more ARM CPUs (like the one in your pocket) than there are server CPUs. Since cellphones and other low power devices are almost all big endian, it seems like network byte order would have been better to use. High powered servers can pay the cost of coding them, but battery powered devices cannot afford to do so.

[niftich]

ARM (since v3) is bi-endian for data accesses and defaults to little. You can confirm this by searching the ARM Information Center [1] for 'support for mixed-endian data', but I can't get a working URL for that exact page.

[1] http://infocenter.arm.com/help/index.jsp

[cmrdporcupine]

ARM is bi-endian but my understanding is almost everybody is running it little-endian these days.

[DonHopkins]

The MIPS is bi-endian, and it's referred to as SPIM when driving backwards.

For some reason, Sun never got around to making a bi-endian version of SPARC called CRAPS.

Speaking of Sun, I have a confession to make: I'm bi-stellar. I love both Star Wars and Star Trek.

[1] https://chortle.ccsu.edu/AssemblyTutorial/Chapter-15/ass15_4...