It's more depressing if you work in a big organization where decisions come down from on-high instead of letting teams decide what's best. (Especially if one of those decisions is so-called Agile practices which were about empowering teams against on-high global decisions from management, but that's a digression.)
But yes, treat it as a job, and make time for "fun time" after work at home using your favorite tools and languages and OSes, and you can still be happy, especially because the bills are being paid. And even in restrictive corporations there still may be opportunities to introduce a little of your favorite thing... Clojure itself "snuck in" at a lot of places because it was just another jar, and it's not too hard to shim in a bit of Java code that then turns things over to the Clojure system. You can also try getting away with internal-only tooling.
If I had stayed at my last job a little longer I would have tried putting more effort into sneaking Common Lisp in. I had a few slackbot tools I wrote in Lisp running on my machine that I turned over (with pre-built binaries) to someone else when I left (but I doubt they're running still). The main application was Java, and there was already mandates from security people and others not to use other JVM languages.. at least in application code. I was thinking (and got a prototype working) of sneaking in Lisp via ABCL, but only for selenium web driver tests. It was a neat trick to show some coworkers a difference in workflow: write or edit a web driver test, one of your asserts fails or an action click on some ID that's not there fails, in Java you get an exception and it's over, you'll have to restart the whole thing, which for us was expensive because these test suites typically spun up huge sets of state before starting. But with Lisp, exceptions don't automatically go back up the stack, but pause at the spot they occurred: from there you can do anything in the debugging REPL that you can do normally, redefine functions, classes, whatever, and then resume the computation from where it left off (or at some higher part of the call tree stack if you prefer), thus no expensive restart.
There's also ways to introduce things you like that aren't just different languages. My team started doing "lunch and learns" at most once a week (sometimes less often); if anyone wanted to talk about whatever for 30-60+ mins during a lunch period we'd get together and do it. Sometimes that would be about specific work things being built, sometimes it would be about external stuff, ideas (e.g. the Mikado Method) or tools. Once I did a brief presentation about property testing and later on got the quicktheories library for Java into the codebase and handling some tests, and ended up not being the only one to occasionally make use of it.