As an ops guy that needs to look after many different configs for many different clients all using many different stacks, your comment surprises me. Configurat

As an ops guy that needs to look after many different configs for many different clients all using many different stacks, your comment surprises me. Configuration being solved within the software itself? Either I am going to end up with "magic" that may or may not work, and may or may not behave predictably in a given scenario (predictable behaviour is somewhat important for ops), or I am going to end up with every single config scenario enshrined within the software itself, something that I thought was established as a software anti-pattern around the time of Ada Lovelace. As the OP stated, the "transparent" option is meaningless without a manual. The nginx (or whatever verbose software config option set) syntax is meaningful, and more importantly, predictable. By spelling out those lines I know exactly what I can expect the software to do in some given scenario. The whole "I don't want to worry about/understand configuration" meme is dangerous. You end up with no real understanding of how your stack functions. You are trading off deep understanding of your stack - a benefit for the lifetime of your product - with reducing 30 minutes configuring stuff to 5, which buys you 25 minutes not having to grok the engine of your app. I personally don't care about having to spend time to configure. I don't care if it is written in Golang, Python, C++, or Sanskrit. I care about performance, security, footprint, and configurability. Remove any of those, and your fancy new toy service just went from "might be interesting for production" to "useless". Ops and magic don't mix very well. I'm surprised this actually needs to be explained. As for it being good for an ego, that kind of statement is ridiculous.