> (as far as I'm aware) C is the only language that lets you specify a binary format and just use it.

I assume they mean:

    struct foo { fields; };
    foo *data = mmap(…);

If you want to access a file containing a bunch of records using mmap, and you want a well defined format and good performance, then use something actually intended for the purpose. Cap’n Proto and FlatBuffers are fast but often produce rather large output; protobuf and its ilk are more space efficient and very widely supported; Parquet and Feather can have excellent performance and space efficiency if you use them for their intended purposes. And everything needs to deal with the fact that, if you carelessly access mmapped data that is modified while you read it in any C-like language, you get UB.

If the real goal of TFA was to praise C's ability to reinterpret a chunk of memory (possibly mapped to a file) as another datatype, it would have been more effective to do so using C functions and not OS-specific system calls. For example:

  FILE *f = fopen(...);
  uint32_t *numbers;
  fread(numbers, ..., f);

  access numbers[...]

  frwite(numbers, ..., f);
  fclose(f);

All these methods are in the standard library, i.e. they work on all platforms. The C code is specific to POSIX; Windows supports memory mapped files too but the APIs are quite different.

When I was first taught C formally, they definitely walked us through all the standard FILE* manipulators and didn't mention mmap() at all. And when I first heard about mmap() I couldn't imagine personally having a reason to use it.

I'm not sure what the author really wants to say. mmap is available in many languages (e.g. Python) on Linux (and many other *nix I suppose). C provides you with raw memory access, so using mmap is sort-of-convenient for this use case.

But if you use Python then, yes, you'll need a bytearray, because Python doesn't give you raw access to such memory - and I'm not sure you'd want to mmap a PyObject anyway?

Then, writing and reading this kind of raw memory can be kind of dangerous and non-portable - I'm not really sure that the pickle analogy even makes sense. I very much suppose (I've never tried) that if you mmap-read malicious data in C, a vulnerability would be _quite_ easy to exploit.

https://docs.oracle.com/javase/8/docs/api/java/nio/MappedByt...

https://learn.microsoft.com/en-us/dotnet/api/system.io.memor...

https://learn.microsoft.com/en-us/windows/win32/memory/creat...

Memory mapping is very common.

> Look inside

> Platform APIs

Ok.

I agree platform APIs are better than most generic language APIs at least. I disagree on mmap being the "best".

> This simply isn't true on memory constrained systems — and with 100 GB files — every system is memory constrained.

I suppose the author might have a point in the context of making apps that constantly need to process 100GB files? I personally never have to deal with 100GB files so I am no one to judge if the rest of the article makes sense.

C has those too and am glad that they do. This is what allows one to do other things while the buffer gets filled, without the need for multithreading.

Yes easier standardized portable async interfaces would have been nice, not sure how well supported they are.

POSIX has the best API. C has `fopen` which, while not terrible, isn't what I'd call "great"

I agree that the model of mmap() is amazing, though: being able to treat a file as just a range of bytes in memory, while letting the OS handle the fussy details, is incredibly useful. (It's just that the OS doesn't handle all of the fussy details, and that's a pain.)

Also using mmap is not as simple as the article lays out. For example what happens when another process modifies the file and now your processes' mapped memory consists of parts of 2 different versions of the file at the same time. You also need to build a way to know how to grow the mapping if you run out room. You also want to be able to handle failures to read or write. This means you pretty much will need to reimplement a fread and fwrite going back to the approach the author didn't like: "This works, but is verbose and needlessly limited to sequential access." So it turns out "It ends up being just a nicer way to call read() and write()" is only true if you ignore the edge cases.

[1] - https://sqlite.org/fasterthanfs.html

When a developer that usually consumes the language starts critiquing the language.

I could go on as to why it's a bad signal, psychologically, but let's just say that empirically it usually doesn't come from a good place, it's more like a developer raising the stakes of their application failing and blaming the language.

Sure one out of a thousand devs might be the next Linus Torvalds and develop the next Rust. But the odds aren't great.

No it doesn't. If you have a file that's 2^36 bytes and your address space is only 2^32, it won't work.

On a related digression, I've seen so many cases of programs that could've handled infinitely long input in constant space instead implemented as some form of "read the whole input into memory", which unnecessarily puts a limit on the input length.