> Technical and human pluralism enriches the world. Monocultures do not.<p>Unlike human culture, tech cultures can't communicate to enrich one-another. (The people <i>in them</i> can, but this is a different thing.)<p>To explain what I mean: you can't import a Ruby library into a Python program. You <i>can</i> import a C library in a Rust program, or vice-versa—but that's a special case. Even then, you can't <i>write a patch for</i> a C library in Rust, or vice-versa, because the original maintainers of the library you want to contribute to are only going to accept contributions in languages they understand and can maintain directly.<p>I really believe that fixing this—decoupling "runtime/platform" from "language semantics", and "language semantics" from "syntax"—is the single most important thing that will happen in software engineering in the next 20 years.<p>Imagine a program somewhat like go-fmt(1), that would run on checkout of a source repo, to transform a base-level AST into the syntactic representation of your choice, and pattern-match-decompile any low-level statements with high-level "shape" into the macro-statements in your chosen language that would generate them[1]. Imagine every library being not only available in every language, but able to be contributed to by programmers who know any language. Etc.<p>The result would be, in one sense, a "monoculture"—a single ecosystem of libraries, rather than 12 ecosystems between the CRT, the JVM, the CLR, the Erlang VM, etc. But it wouldn't disallow competition between versions of said libraries—just allow obvious winners to win once-and-for-all, instead of limiting their success to their technological "country of citizenship."<p>---<p>[1] Or, better yet, a FUSE server where an underlying directory of AST files gets mounted as syntaxified files. Much cleaner from the rest of the toolchain's perspective.