I admire experimentation, so below comments should preferably be considered constructive.. > I want the binary modules any user of Olin would upload today to b

I admire experimentation, so below comments should preferably be considered constructive.. > I want the binary modules any user of Olin would upload today to be still working, untouched, in 5 years, assuming its dependencies outside of the module still work There are only 3 program formats that enjoyed anywhere like that kind of longevity - PE, Linux ELF, and Jar, all with significant money behind them. Of these, only PE has managed anything like ABI and dependency compatibility across more than 10 years, and that's because of explicitly obsessive compatibility concerns baked into the culture of the company behind it. The nearest best example to PE is Linux Intel ELF, where despite explicit efforts, and where glibc which nearly-almost-if-you-squint manages long term ABI stability, and the kernel which nearly-almost-if-you-squint manages long term compatibility with glibc, you can run a terminal program compiled at the start of the millennium if you boot with the right kernel command line options, so long as you also run it with an ancient buggy libc, and that program has no other system dependencies. Coming from Python land, I can say categorically that any attempt to maintain feverishly accurate compatibility for a rich set of interfaces across a community is almost a pointless effort, the options always degrade to running ancient buggy deps, or updated deps with broken interfaces. The Linux kernel barely manages it despite a strict policy, and they break it occasionally due to security concerns. Downstream community projects follow the whim of whoever is contributing code on that particular day, and their motivations are rarely if ever "compatibility". That is not to say a community effort couldn't manage >10 year compatibility, but that such concerns must be a foremost priority (rather than a cute goal) if there is even a dying chance of the attempt succeeding in the long term. It seems better that the inevitability of incompatibility is honestly accepted and designed for rather than hoping things will just work out. --- > The core idea is that everything is a file, to the point that the file descriptor and file handle array are the only real bits of persistent state for the process Again an admirable goal, but this is Stockholm syndrome in its purest form, and learning completely the wrong lessons from UNIX land. Files are a shit abstraction, but ignoring those, streams even moreso. Very few elements of a modern application even at the lowest tiers lend themselves well to being expressed as a serialized bytestream. The minimum primitive (and happy to share many references to support this) should be something like messages and ports. Streams can be expressed as messages, but the converse is not true without application-specific protocol scaffolding, of which there are a thousand examples on every modern UNIX system as a consequence of UNIX picking streams. --- > When a dagger process is opened, the following files are open: Sequentially numbered transparent handles are a mistake, as are predefined resources, they allow code to make incorrect assumptions that are difficult to manage over the life of a system. You say that glibc should be built on these APIs, yet one of the principal restrictions glibc suffers from is its inability to open long-lived file handles that might conflict with program assumptions -- assumptions often make implicitly without any conscious thought on the part of the programmer. Incremental numbering SUCKS. A few years back Linux even considered adding a brand new fd namespace just so glibc could safely open files, all because of predictable numbered handles with assumed semantics that did not exist. Try to learn from NT and elsewhere here -- the user receives an opaque word, no predefined words exist, and an interface is provided to grant access to any standard resources without introducing global state. --- > open, close, read, write, sync But I thought everything is a file.. why do we need these? Why can't we express these as files too? Due to incorrect lessons above, in a real world system this list will inevitably grow to multiple times its original size. What does sync mean on a socket? How do I eject a DVD drive? How does an application read the system time? By opening some "time://" and reading a serialized time representation? Good luck with nanosecond resolution when microseconds are already lost on scaffolding and maybe parsing some ASCII format timestamp, and so a "one time only" specialized time() call appears. 10 years later and you have hundreds of entries just like /usr/share/man/man2 on a typical UNIX, probably alongside something like ioctl(). But of course this time will be different --- > the open call (defined later), a file URL is specified instead of a file name. This allows for Dagger to natively offer programs using it quick access to common services like HTTP, logging or pretty much anything else. The open call prototype as defined is totally unusable for any kind of network application. There is no room for setting any kind of meaningful options outside a single bitfield, and so already if I wanted to make any kind of custom HTTP request, the supplied interface is useless and I must link a module with a real client built on top of the tcp:// handler. There seems to be no long term sense whatsoever in baking a handful of protocols into the "filesystem" interface, especially not with these APIs. --- > I’d like to add the following handlers in the future: I see they have thought of time:// already! By discarding one of the few remaining uniformities of the UNIX file API - the namespace it exports. It already looks like we're coping with a bad base abstraction by shoving everything we need into magic strings. What happens if I only read 2 bytes from time://? Do I get pieces of the last sampled timestamp because some internal buffering now exists, or do i get half the old timestamp half the new one, or do I continually get the first 2 bytes of unrelated timestamps, or perhaps we simply return an error because the buffer wasn't big enough? It's almost like even a timestamp doesn't really fit the stream-of-bytes file abstraction. --- Very happy to see all these new WebAssembly efforts, but this one's present design fails to learn any lesson from our past suffering.