Endian wars and anti-portability: this again? • Hacker News Board

Re: Endian wars and anti-portability: this again?

#71

Post by zephen » Tue, Apr 07, 2026, 3:30 PM UTC

Joker_vD wrote: post #51

zephen wrote: post #28

Earlier quoted context omitted.

Your example is only for dumping memory. > this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it Computers really don't care. Literally. Same number of gates either way. But for everything besides dumping it makes sense that the least significant byte and the least significant bit are numbered starting from zero. It makes intuitive mathematical sense.

> Computers really don't care. Literally. Same number of gates either way. Eh. That depends; the computer architectures used to be way weirder than what we have today. IBM 1401 used variable-length BCDs (written in big-endian); its version of BCDIC literally used numbers from 1 to 9 as digits "1" to "9" (number 0 was blank/space, and number 10 would print as "0"). So its ADD etc. instructions took pointers to the las…

My comment was in response to the parent's

> FWIW, this is a weak argument for what computers should do; if LE is more efficient for machines then let them use it

I should have fleshed it out more fully, but basically, it was about how when you design an ALU, it's literally the same number of gates whether you swap the pins when you connect it to the rest of the system or not.

Using the computer is, of course, a different story that depends a lot on design decisions made when implementing it, and depending on your usage, endianness can matter more.

Re: Endian wars and anti-portability: this again?

#72

Post by jltsiren » Wed, Apr 08, 2026, 3:35 AM UTC

nextaccountic wrote: post #67

jltsiren wrote: post #25

Earlier quoted context omitted.

Wasm is in an awkward place, because Memory64 is widely but not universally supported. Which means that if you want to support Wasm, you probably have to support 32-bit environments in general. Depending on the project, that can be trivial, but it may also require you to rewrite a lot of low-level code in the project and its dependencies.

This just means 32 bits is still relevant.. Also: why not riscv? Anyway, I think that most pain for being low level and portable is due to C and C++, and it's not as painful in Rust. In Rust it's not as common to use non-portable integers like C's int (there is isize/usize but they are used for indexing; logic is supposed to be done in i32/u32/i64/u64), and the Rust stdlib comes with excellent support for dealing wit…

I think it's the opposite. Rust encourages you to use usize everywhere, because most interfaces use it and you need explicit casts between integer types. In C++, you typedef custom integer types everywhere and rely on implicit casts to make things work painlessly. And then you hope that you are not shooting yourself in the foot with some edge cases in the casts.

Re: Endian wars and anti-portability: this again?

#73

Post by nextaccountic » Sat, Apr 11, 2026, 3:49 AM UTC

jltsiren wrote: post #72

nextaccountic wrote: post #67

Earlier quoted context omitted.

This just means 32 bits is still relevant.. Also: why not riscv? Anyway, I think that most pain for being low level and portable is due to C and C++, and it's not as painful in Rust. In Rust it's not as common to use non-portable integers like C's int (there is isize/usize but they are used for indexing; logic is supposed to be done in i32/u32/i64/u64), and the Rust stdlib comes with excellent support for dealing wit…

I think it's the opposite. Rust encourages you to use usize everywhere, because most interfaces use it and you need explicit casts between integer types. In C++, you typedef custom integer types everywhere and rely on implicit casts to make things work painlessly. And then you hope that you are not shooting yourself in the foot with some edge cases in the casts.

That's not my experience. Yes casts are annoying but in Rust usize generally means something is an index to a Vec or arena (generally speaking, it means the id of some entity). You generally should not do math with indices in your business logic but rather use some higher level interface that does the math for you, because if you mess up you will have an out of bounds bug (which in Rust is not UB, but it's still a panic). If you keep your usizes to be just indices, they will not pose a portability problem.

When I talk about a higher level interface it may be something like this https://crates.io/crates/typed-generational-arena those sort of things are very common in Rust. In here the index is an usize, but you don't directly do math with it (also you have a generation number to guard against index reuse), so you never experience any `as usize` thing.

Of course that's not applicable to everything. Some domains will naturally require doing arithmetic with indices, which is annoying in Rust. Hopefully you enclose this into a library and try to forget the horrors (rather than using usize everywhere, which is objectively the wrong thing to do)

Then you have libraries like petgraph that does use u32 indices by default, to save memory https://docs.rs/petgraph/latest/petgraph/graph/type.DefaultI...