LEON, used by the European Space Agency, is big endian.

Should have been called BEON.

10 years ago the fastest BE machines that were practical were then-ten year old powermacs. This hasn’t really changed. I guess they’re more expensive now.

e6500/T4240 are faster than powermacs. Not sure how rare they are nowadays, we didn't have any trouble buying some (on eBay). 12×2 cores, 48GB RAM, for BE that's essentially heaven…

BE isn’t technically dead buts it’s practically dead for almost all projects. You can static_assert byte order and then never think about BE ever again.

All of my custom network serialization formats use LE because there’s literally no reason to use BE for network byte order. It’s pure legacy cruft.

...Until you find yourself having to workaround legacy code to support some weird target that does still use BE. Speaking from experience (tbf usually lower level than anything actually networked, more like RS485 and friends).

18 years in my career and I’m still waiting for that BE target to rear its ugly head.

I’m more than happy to static_assert little endian. If any platform needs BE support then I’ll add support to the minimum amount of libraries necessary to do so. Super easy.

Here’s the thing. If you wrote BE compatible code today you probably dont even have a way to test it. So you’re adding a bunch of complexity and doing a bunch of work that you can’t even verify is correct! Complete and total waste of time.

Java VM is BE.

This is misleading at best. The JVM only exposes multibyte values to ordinary applications in such a way that byte order doesn't matter. You can't break out a pointer and step through the bytes of a long field to see what order it's in, at least not without the unsafe memory APIs.

In practice, any real JVM implementation will simply use native byte order as much as possible. While bytecode and other data in class files is serialized in big endian order, it will be converted to native order whenever it's actually used. If you do pull out the unsafe APIs, you can see that e.g. values are little endian on x86(-64). The JVM would suffer from major performances issues if it tried to impose a byte order different from the underlying platform.

One relatively commonly used class which exposes this is ByteBuffer and its Int/Long variants, but there you can specify the endianness explicitly (or set it to match the native one).

IBM's Power chips can run in either little or big modes, but "used a lot" is a stretch

Most PowerPC related stuff (e.g. Freescale MPC5xx found in a bunch of automotiver applications) can run in either big or little endian mode, as can most ARM and MIPS (routers, IP cameras) stuff. Can't think of the last time I've seen any of them configured to run in big endian mode tho.

For the large Power ISA machines, it's most commonly when running AIX or IBM i these days, though the BSDs generally run big too.

Some ARM stuff.

Apart from IBM Power/AIX systems, SPARC/Solaris is another one. I wouldn't say either of these are used a lot, but there's a reasonable amount of legacy systems out there that are still being supported by IBM and Oracle.