Tbh, thought this will be just another proto (where proto:=9p in this case) implementation without a use-case in mind. Pleasantly surprised this isn't the case.
As per #Reasoning section, author made this to provide* a procfs-like API for Erlang. If only think of Erlang as programming language, this may sound odd. What it means for a programming language to have procfs? Well, Erlang VM is more like a tiny operating system than a typical runtime. It has its own processes, scheduler, supervisor, and message parsing. Exposing these "system objects" via a fs API is just like /proc exposes kernel state on Linux.
*A similar FUSE-based NIF-implemented project is mentioned but author bring up cross-compilation as problem. Perhaps more important, libraries used through NIF may degrade performance or even crash the entire VM. So in Erlangland re-implementing protocols in pure-Erlang is quite common.
forgotpwd16•1h ago
As per #Reasoning section, author made this to provide* a procfs-like API for Erlang. If only think of Erlang as programming language, this may sound odd. What it means for a programming language to have procfs? Well, Erlang VM is more like a tiny operating system than a typical runtime. It has its own processes, scheduler, supervisor, and message parsing. Exposing these "system objects" via a fs API is just like /proc exposes kernel state on Linux.
*A similar FUSE-based NIF-implemented project is mentioned but author bring up cross-compilation as problem. Perhaps more important, libraries used through NIF may degrade performance or even crash the entire VM. So in Erlangland re-implementing protocols in pure-Erlang is quite common.