across different systems for reasons that are arbitrary
but that matters not
the JVM architects decided, for their own reasons, that big endianness was the one true way to organize bytes
and Microsoft, being the arch-nemesis of any company run by open source birkenstock-wearing hippies
decided that little endianness must be the one true way
file format and wire compatibilities were hopelessly dashed
and many heated arguments between bearded UNIX-y types ensued
and for all a time, there was nothing but darkness spread across the land
of unspeakable power
distributed databases, batch processing systems, streaming ETL pipelines
much like the citizens of East Germany living in the shadow of the Berlin wall, we dismissed these stories as just JVM propaganda
and chuckled smugly to ourselves as we patiently waited for SQL Server 2013 Super Streaming MapReduce Does Everything Edition
but as the years ticked by, these stories stepped into the realm of fact
and us CLR developers, seeing with our own eyes for the first time, decided that the great Endian war must come to an end
so we learned how to use
byte[].Reverse()
But no, my sweet summer child, that was not the end
and thus the small light of hope we only just recently lit was in danger of being squelched by the aftermath of the Endian war after all
and finally tore the great format wall down once and for all
ok, I can't keep telling this like an Epic poem
gave it everything I had
lol
and make sure both ends serialize using that
might be as simple as adding a JSON serializer as the default for Akka
and then on the CLR side you'll need to account for endianness
probably better off just making an Akka.IO wrapper in C#
and use that to communicate as a client
rather than attempt to get Akka.Remote / Akka.Cluster to be JVM-compatible
was wondering when Galdalf the Red, Blue, Yellow and Green would come in
lol @nvivo
that's my get out of jail free card