Author of the post here. Don't worry, I am taking them as such.
> It seems better that the inevitability of incompatibility is honestly accepted and designed for rather than hoping things will just work out.
How would this look? I'm interested by what you mean by this. I'm not sure how incompatibility with things like reading out sequential memory is going to be tolerable though.
> 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.
Yes, I eventually want to settle on messages. The reason I have picked file I/O in the meantime is so I can hack something together that will "just work". From a generic level, I don't know what memory addresses are safe to write to. Using the read() function makes the program choose for itself.
Streams are a shitty abstraction, but most of the world is currently built on them, so I'm using streams in Dagger if only to make Dagger have to be thrown away in the long run. Streams may be bad in the long term, but for now we can do HTTP via the filesystem calls: https://github.com/Xe/olin/blob/master/internal/abi/dagger/t...
> file descriptors are a mistake
Yeah, I'm betting that they are gonna be a mistake in the long term. I just don't know what abstraction to use that won't be yet.
I guess I sort of am using file streams as messages. I'm gonna see what it would look like to make messages the primitive.
> But I thought everything is a file.. why do we need these? Why can't we express these as files too?
File descriptors are adjectives, system calls are verbs. The verb is the action you want to do, such as read. The adjective is the source, ie the semantically standard input of the process.
> Due to incorrect lessons above, in a real world system this list will inevitably grow to multiple times its original size.
Yep. I'm expecting this design to be wrong in the long term. It really started as an experiment to see how far minimalism could go.
> 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.
https://AzureDiamond:hunter2@bash.org/244321 is what I usually do with URL's and hard-defined authentication tokens. Works for me.
> 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.
Yeah, I'm starting to see that Dagger is WAY TOO MINIMAL. I'm gonna go poke around POSIX and other minimal OS' to see what syscalls they expose. For what it's worth, the Go runtime has its own time() call that I expose here: https://github.com/Xe/olin/blob/master/internal/abi/wasmgo/a...
> Very happy to see all these new WebAssembly efforts, but this one's present design fails to learn any lesson from our past suffering.
The first design always has to be thrown out :D