Write (module) signatures, not (protocol) schemas

For example, a function pointer is a valid argument or return type for a function in most languages, even in C. But almost no protocol schemas support this. In more advanced languages, objects, interfaces, abstract data types, types themselves, type constructors, references to other modules, and many other constructs are valid arguments and return types. You can't express any of that in protocol schemas; this makes many tasks more complicated.

So why do people ever write servers instead of libraries?

A library can do anything that a standalone server can do. But our modern Unix-derived programming environments are slanted towards standalone servers, so some things are easier with standalone servers; hence, servers are almost always the first choice.

Nevertheless, contrary to popular belief, libraries can do anything, including:

• Maintain stable, backwards-compatible interfaces

  The precise details of how to maintain a backwards-compatible signature is language-specific, but it's possible in most languages. For example, don't add a new mandatory argument to an existing function; instead, add an optional argument with a default.

  In fact, a library is strictly more powerful than a protocol schema in this regard: If you really wanted to, you could use a protocol schema directly to define the format of the data passed in and out of the library.

• Be used from, or implemented by, programs written in multiple languages

  The most common way to support cross-language interaction in libraries is to go through the C type system; C functions can be called from, or implemented in, any language with a C FFI. Going through the C type system can be constraining, so there are many projects which allow one language to call functions in another language without going through C. This also allows a signature in one language to have multiple implementations in other languages.

• Be built separately from the rest of the program, and have different dependencies.

  For example, by "shading" dependencies in Java, or with linker scripts, dlmopen or DT_FILTER in C.

• Run in parallel, using multiple cores.

  Obviously: You can run library functions on multiple threads. Different threads can even have different IO and CPU priority levels.

• Be updated without restarting the process using them.

  This field of techniques is called dynamic software updating. These techniques are actually quite easy if the library only does things that one could do over a protocol schema. If the library uses more than that bare minimum of features, dynamic software updating becomes harder, but still possible.

  One interesting use of this ability is to implement extremely high-performance, but backwards-incompatible, wire protocols.

• Isolate failures.

  "Software fault isolation" is all about this; SFI allows a library to be run in the same address space without the ability to interfere with other memory in that address space. Other techniques in this vein are used all the time for emulation and virtualization.

• Access resources on other hosts and in other environments.
  • In general, there's no reason a library can't spin up a stub in some environment, and use that to access resources in that environment, including on remote hosts. I have a constructive proof of this: rsyscall.
  • Distributed languages (including libraries that make existing languages into distributed lanaguages) let you write libraries which access remote resources.
  • Process supervisors can be replaced with a library.

• Have access to resources that the rest of the program isn't allowed to access.

  For example:

  • Javascript running in a browser can access functionality provided by the browser as a library; the browser and the Javascript are running at different privilege levels.
  • An object in a type-safe language can contain capabilities for resources which it uses to implement its methods, without those capabilities being available to the code calling those methods.
  • Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.
  • Capability-safe architectures such as CHERI prevent code from accessing memory that it doesn't have an explicit capability for.
  • Software fault isolation can allow Multics-style "call gates", where a library has a different privilege level from other code.

  You might be concerned about using such fancy techniques. Sometimes, they aren't necessary, because the whole program can safely be given access to the supposedly-privileged resource, perhaps because the resource is one or more of:

  • fast to create (so we can just create them on the fly in the library)
  • cheap to create (so we can give every user their own)
  • already multiplexed and safe to share (it's amazing how easy it is to miss this if you don't explicitly think about it)
  • easily tweaked to be shareable (for example, a resource could be leased out to a user then reset when they're done)
  • or otherwise safe or can be made safe to give to users directly

  Consider this carefully; this point is often non-obvious.