File format for what? Text, graphics, compiled code?

This reminds me of Alan Kay's OOPSLA 1997 presentation "The Computer Revolution Hasn’t Happened Yet" when he describes the Air Force / Burroughs 220 file format from 1961 where the file/tape contained both the data and the procedures to read/write/print them: https://youtu.be/oKg1hTOQXoY?t=1355

I think we know how this story ends https://en.wikipedia.org/wiki/OpenDoc

So you know what is a file format the we would be able to Reed 100 years from now. CSV, json even fits (that is 30 years old now). If you don't know the original way it was created you know what each field I supposed to mean (if done well). Otherwise you look at hex decoded data with no way if knowing how to decide it if you don't have tha spec on how and why this was encoded. Msgpack and cbor are cool but in 100 years there is no way to decide it.

Great! I'll use it.

In the "future."

Nimble? Lance? Also in the future. Maybe.

I'll use Parquet in the present.

One past discussion:

F3: Open-source data file format for the future [pdf] - https://news.ycombinator.com/item?id=45437759 - Oct 2025 (125 comments)

plus this bit:

An Open File Format for storing the information from a forge - https://news.ycombinator.com/item?id=44043253 - May 2025 (1 comment)

Probably not a good idea to name your project “future” anything, if you expect that future to become the present.

Also, f3 is already “fight-flash-fraud”.

F3 seems to be a reasonable archival data format.

I see many replies criticizing F3 as an operational data format, like Parquet. Of course it can't be made as fast in the general case, or as compatible to the existing infrastructure.

OTOH F3 would be easy to decode into almost any of today's accepted formats, and likely to any of tomorrow's data formats. That's where being self-describing and self-unpacking would be important.

This project README is not particularly useful:

It doesn't explain what the project does (a file format for what? Name dropping other things I haven't heard of isn't useful)

There are no examples. It links to a flatbuffer schema which is at least well commented, but is full of deep implementation details.

The point is that within 2-3 minutes I'm not convinced why I care and still don't know enough about what this is to even think back to if if I encounter a scenario in the future where it would be useful.

> designed with efficiency, interoperability, and extensibility in mind. It provides a data organization that rectifies the layout shortcomings of the last-generation formats like Parquet,

This is all marketing speak that says nothing.

> maintaining good interoperability and extensibility (a.k.a future-proof) via embedded Wasm decoders What does this even mean? Providing a decoder is no guarantee of futureproofness.

As appealing as this is, it will never gain traction without some backwards compatibility with Parquet and wide adoption of query engines to implement that backwards compatible path.