I'm in the camp that sadly does not have easy options to choose a different language at work (I mainly work in C#), but I'm still very interested in learning ne

I'm in the camp that sadly does not have easy options to choose a different language at work (I mainly work in C#), but I'm still very interested in learning new programming paradigms and techniques. From this view, and regularly having similar experience with code I have to dig up for whatever reason, I've come to wonder whether the argumentation on languages here doesn't ignore a very important aspect: The blogpost (as many before it) presents the process of understanding your code as a tooling problem. I slowly come to think that the real problem here is educating people to write understandable code that those tools really solve. I've wrestled with some horrible in house Java application multiple coworkers produced for quite some time now. It has mutable state everywhere and is full of hacks, bugs and race conditions, although the actual problem really isn't that complex. (It is so bad that it looks like management even might get past the sunk cost fallacy regarding a rewrite directly after it has been "finished"! I've never experienced that one so far.) After thinking it through for quite some time, I'm convinced that there's a very simple (and rather elegant) solution to this, but if you want to tackle such a project, you should at least know about immutable datastructures, record types, algebraic datatypes and the basic concepts of idempotency and CSP. But everytime I try to nudge someone in the dev team in the "right" direction, I feel considerable friction in this regard. So, more and more, I come to think of the biggest worth of languages like Rust, Elm, Clojure, Erlang and so on being that they force programmers to think in different ways (and grow in the process) -- something that gets handwaved away in other circumstances with "well, it has worked for me so far…".