Write libraries instead of services, where possible

And before Elixir, Erlang itself was a frequent visitor on the HN front page. Still is.

> But if you didn't have the service in the first place - if there was only the library, containing all the functions, doing whatever the service was supposed to do in the first place - you wouldn't have this problem. Users who don't upgrade would suffer whatever problem exists in the initial version of the library, and everyone else would be fine.

While I tend to prefer a library over a service where possible, there’s an implication I didn’t see mentioned: if your use case involves communication between library instances (or collaboration on shared data) at runtime, you might have to choose between requiring users to only run matching versions of the library (complicates library use) or implementing very strong backwards compatibility (preferable, but can seriously complicate iteration, especially during early stages).

Yes, that's a better example!

(I thought your initial point was good, just that the argument for it wasn't as strong as it could be.)

This reminds me one this section from The Art of Unix Programming

http://www.catb.org/esr/writings/taoup/html/ch04s04.html

> One consequence of the emphasis that the Unix programming style put on modularity and well-defined APIs is a strong tendency to factor programs into bits of glue connecting collections of libraries, especially shared libraries (the equivalents of what are called dynamically-linked libraries or DLLs under Windows and other operating systems).

>If you are careful and clever about design, it is often possible to partition a program so that it consists of a user-interface-handling main section (policy) and a collection of service routines (mechanism) with effectively no glue at all. This approach is especially appropriate when the program has to do a lot of very specific manipulations of data structures like graphic images, network-protocol packets, or control blocks for a hardware interface. Some good general architectural advice from within the Unix tradition, particularly applicable to the resource-management challenges of this sort of library is collected in The Discipline and Method Architecture for Reusable Libraries [Vo].

>Under Unix, it is normal practice to make this layering explicit, with the service routines collected in a library that is separately documented. In such programs, the front end gets to specialize in user-interface considerations and high-level protocol. With a little more care in design, it may be possible to detach the original front end and replace it with others adapted for different purposes. Some other advantages should become evident from our case study.

>There is a flip side to this. In the Unix world, libraries which are delivered as libraries should come with exerciser programs.

>APIs should come with programs, and vice versa. An API that you must write C code to use, which cannot be invoked easily from the command line, is harder to learn and use. And contrariwise, it's a royal pain to have interfaces whose only open, documented form is a program, so you cannot invoke them easily from a C program — for example, route(1) in older Linuxes. -- Henry Spencer

>Besides easing the learning curve, library exercisers often make excellent test frameworks. Experienced> Unix programmers therefore see them not just as a form of thoughtfulness to the library's users but as an indication that the code has probably been well tested.

>An important form of library layering is the plugin, a library with a set of known entry points that is dynamically loaded after startup time to perform a specialized task. For plugins to work, the calling program has to be organized largely as a documented service library that the plugin can call back into.

How does the liscence agreement with Google look like, you just pay per Query? Does Google prohibit caching? Just curious as I remember reading nightmare stories of companies basing their business model on Google services (maps).