Hacker News Reader

Comment by jagged-chisel | Hacker News Reader

Any long-lived executable sits in memory (notwithstanding paging, which the database server is also subject to), and such an executable is free to maintain any files it accesses in memory as well.

View on HN

I think what was being referred to is the technique of defining a program, not as source code files which are then compiled/run in an interpreter, but as an in-memory VM environment (think REPLs). The memory-based environment can then be saved to a file, similar to making a core dump.

This changes the structure of programs from a file/disk based structure, to the potentially richer structure of the programming environment (e.g. graphs of objects). Although it comes with disadvantages like losing the tool inter-operability of files.

That sounds like doing for code what we used to do for deployments before docker/kubernetes. Like going back from a declarative and reproducible aproach to a more procedural one. There's good reasons infrastructure as code took hold.

I have a hard time seeing advantages of ditching files. I like this concept, but you can have it both ways (come up with a graphical notation that you can then manipulate with graph like tools), but at the end of the day you need a source of truth, and the file metaphor (a named region of code) is hard to beat (impossible to beat?). Even databases store things as files.

File systems are just one approach to storage. Databases can use file systems, block devices, or object-based storage (such as distributed storage systems, e.g. Ceph, Amazon S3). Traditional file systems are, by themselves, inadequate for many use case, as they don't provide things like versioning.

The strength of the file system, is that much tooling already exists for it.

Reply on news.ycombinator.com