Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on the Word Spec in Rust

tritium.legal

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Thoughts on the Word Spec in Rust

#21

Post by amelius »

OskarS wrote: post #17
amelius wrote: post #14

The original Word format was a literal dump of a part of the data segment of the Word process. Basically like an mmapped file. Super fast. It is a pity that modern languages and their runtimes do not allow data structures to be saved like that.

You can absolutely save data like that, it's just that it's a terrible idea. There are obvious portability concerns issues: little-endian vs. big endian, 32-bit vs. 64-bit, struct padding, etc. Essentially, this system works great if you know the exact hardware and compiler toolchain, and you never expect to upgrade it with things that might break memory layout. Obviously this does not hold for Word: it was written o…

It's only a terrible idea because our tools are terrible.

That's exactly the point!

(For example, if Rust would detect a version change, it could rewrite the data into a compatible format, etc.)

Re: Thoughts on the Word Spec in Rust

#22

Post by OskarS »

skywal_l wrote: post #19
OskarS wrote: post #17

Earlier quoted context omitted.

You can absolutely save data like that, it's just that it's a terrible idea. There are obvious portability concerns issues: little-endian vs. big endian, 32-bit vs. 64-bit, struct padding, etc. Essentially, this system works great if you know the exact hardware and compiler toolchain, and you never expect to upgrade it with things that might break memory layout. Obviously this does not hold for Word: it was written o…

Andrew Kelley (author of zig) has a nice talk about programming without pointers allowing ultra fast serialize/deserialization. [0] And then you have things like cap'n'proto if you want to control your memory layout. [1] But for "productivity" files, you are essentially right. Portability and simplicity of the format is probably what matters. [0]: https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e83... [1]: h…

That is true, cap’n proto and flatbuffers are excellent realizations of this basic concept. But that’s very different thing from what the commenter is talking about Word doing in the 90s, of just memory-mapping the internal data structures and be done with it.

Re: Thoughts on the Word Spec in Rust

#23

Post by actionfromafar »

OskarS wrote: post #22
skywal_l wrote: post #19

Earlier quoted context omitted.

Andrew Kelley (author of zig) has a nice talk about programming without pointers allowing ultra fast serialize/deserialization. [0] And then you have things like cap'n'proto if you want to control your memory layout. [1] But for "productivity" files, you are essentially right. Portability and simplicity of the format is probably what matters. [0]: https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e83... [1]: h…

That is true, cap’n proto and flatbuffers are excellent realizations of this basic concept. But that’s very different thing from what the commenter is talking about Word doing in the 90s, of just memory-mapping the internal data structures and be done with it.

Smalltalk is something like that.

Re: Thoughts on the Word Spec in Rust

#24

Post by johngossman »

amelius wrote: post #21
OskarS wrote: post #17

Earlier quoted context omitted.

You can absolutely save data like that, it's just that it's a terrible idea. There are obvious portability concerns issues: little-endian vs. big endian, 32-bit vs. 64-bit, struct padding, etc. Essentially, this system works great if you know the exact hardware and compiler toolchain, and you never expect to upgrade it with things that might break memory layout. Obviously this does not hold for Word: it was written o…

It's only a terrible idea because our tools are terrible. That's exactly the point! (For example, if Rust would detect a version change, it could rewrite the data into a compatible format, etc.)

At which point you're not just memory mapping the file. And if the new version changes the size of the object, it doesn't pack in the same place in memory, so you have to repack before saving. Even serializing with versioning is very hard. Memory mapping is much worse. Several other comments indicate that I am not the only one with bad experiences here.

Re: Thoughts on the Word Spec in Rust

#25

Post by olivermuty »

piker wrote: post #6
olivermuty wrote: post #3

would be cool if they published this as oss

Thanks for the kind words, and I have given it serious thought. It's definitely not impossible in the future. I just don't think there is enough interest right now in contributing to the underlying tech without generalizing it so much that it basically becomes an inferior LibreOffice. Instead, the business model for Tritium is to give away the niche legal product for free to the community, but charge commercial users…

By «this» I meant the docx parts, not the rest ;)
Post reply on HN