logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

On-the-traits-of-good-replacements.md (5039B)

    

  1. ---
  2. title: A great alternative is rarely fatter than what it aims to replace
  3. date: 2021-02-21
  4. ---
  6. This is not always true, but in my experience, it tends to hold up. We often
  7. build or evaluate tools which aim to replace something kludgy^Wvenerable.
  8. Common examples include shells, programming languages, system utilities, and so
  9. on. Rust, Zig, etc, are taking on C in this manner; so too does zsh, fish, and
  10. oil take on bash, which in turn takes on the Bourne shell. There are many
  11. examples.
  13. All of these tools are fine in their own respects, but they have all failed to
  14. completely supplant the software they're seeking to improve upon.[^5] What these
  15. projects have in common is that they *expand* on the ideas of their
  16. predecessors, rather than *refining* them. A truly great alternative finds the
  17. nugget of truth at the center of the idea, cuts out the cruft, and solves the
  18. same problem with less.
  20. [^5]: Some of the listed examples have not given up and would prefer that I say something to the effect of "but the jury is still out" here.
  22. This is one reason I like Alpine Linux, for example. It's not really aiming to
  23. replace any distro in particular so much as it competes with the Linux ecosystem
  24. as a whole. Alpine does this by being *simpler* than the rest: it's the only
  25. Linux system I can fit more or less entirely in my head. Compare this to the
  26. most common approach: "let's make a Debian derivative!" It kind of worked for
  27. Ubuntu, less so for everyone else. The C library Alpine ships, [musl
  28. libc](https://musl.libc.org), is another example: it aims to replace glibc by
  29. being leaner and meaner, [and I've talked about its success in this respect
  30. before][0].
  32. [0]: https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html
  34. Go is a programming language which has done relatively well in this respect. It
  35. aimed to fill a bit of a void in the high-performance internet infrastructure
  36. systems programming niche,[^1] [^2] and it is markedly simpler than most of the
  37. other tools in its line of work. It takes the opportunity to add a few
  38. innovations — its big risk is its novel concurrency model — but Go
  39. balances this with a level of simplicity in other respects which is unchallenged
  40. among its contemporaries,[^3] and a commitment to that simplicity which has
  41. endured for years.[^4]
  43. [^1]: That's a lot of adjectives!
  44. [^2]: More concisely, I think of Go as an "internet programming language", distinct from the systems programming languages that inspired it. Its design shines especially in this context, but its value-add is less pronounced for other tasks in the systems programming domain - compilers, operating systems, etc.
  45. [^3]: [The Go spec](https://golang.org/ref/spec) is quite concise and has changed very little since Go's inception. Go is also unique among its contemporaries for (1) writing a spec which (2) supports the development of multiple competing implementations.
  46. [^4]: Past tense, unfortunately, now that Go 2 is getting stirred up.
  48. There are many other examples. UTF-8 is a simple, universal approach which
  49. smooths over the idiosyncrasies of the encoding zoo which pre-dates it, and has
  50. more-or-less rendered its alternatives obsolete. JSON has almost completely
  51. replaced XML, and its grammar famously fits on a business card.[^6] On the other
  52. hand, when zsh started as a superset of bash, it crippled its ability to compete
  53. on "having less warts than bash".
  55. [^6]: It is possible that JSON has achieved *too much* success in this respect, as it has found its way into a lot of use-cases for which it is less than ideal.
  57. Rust is more vague in its inspirations, and does not start as a superset of
  58. anything. It has, however, done a poor job of scope management, and is
  59. significantly more complex than many of the languages it competes with, notably
  60. C and Go. For this reason, it struggles to root out the hold-outs in those
  61. domains, and it suffers for the difficulty in porting it to new platforms, which
  62. limits its penetration into a lot of domains that C is still thriving in.
  63. However, it succeeds in being much simpler than C++, and I expect that it will
  64. render C++ obsolete in the coming years as such.[^7]
  66. [^7]: Despite my infamous distaste for Rust, long-time readers will know that where I have distaste for Rust, I have passionate scorn for C++. I'm quite glad to see Rust taking it on, and I hope very much that it succeeds in this respect.
  68. In computing, we make do with a hodge podge of hacks and kludges which, at best,
  69. approximate the solutions to the problems that computing presents us. If you
  70. start with one such hack as the basis of a supposed replacement and build *more*
  71. on top of it, you will inherit the warts, and you may find it difficult to rid
  72. yourself of them. If, instead, you question the premise of the software,
  73. interrogate the underlying problem it's trying to solve, and apply your
  74. insights, plus a healthy dose of hindsight, you may isolate what's right from
  75. what's superfluous, and your simplified solution just might end up replacing the
  76. cruft of yore.