The alternative, to be like me, a stuck-in-the-past old guy who knows how to use only a few tools really well is probably also not optimal.
But the chase-the-next-fad attitude can be just as lethal for your productivity as having no options at all.
However, I notice that languages wash over HN like waves. A few weeks ago there were a glut of back-to-back Clojure posts. Last week it was all-Go-all-the-time, and over the past few days Rust has surged.
This wave pattern is a cultural quirk of HN, rather than serious indicators of what you should be pushing for within your company, or where you should be taking your career long-term.
That said it is not a silver bullet, split brain problems and other nasties remain hard.
I don't think you can rip off the good bits of Erlang without using the Erlang VM and associated plumbing.
The problem is that you end up needing to do 'real world' stuff, and hit something like this:
Very frustrating. But then again, if it were easy it wouldn't make the money that it does. A defensible moat that is made out of hard work is a good thing in many ways.
As these things go lots of money was blown, egos got frayed, potential customers were disappointed and time was wasted.
All in all a huge learning experience but ultimately mostly a harsh lesson in not biting off more than you can chew and how not to run a project. I was involved as a coder rather than in any other capacity but some of the responsibility for the way the project was run surely rubs off on me. For one I should have probably thrown in the towel earlier when I realized in how many dimensions we were deficit.
There wasn't a single point in time where I thought 'this is not the right way' other than right at the beginning, but once involved (originally just to fix 'a few bugs') I felt that I should give it my 200% to make it work.
Over the course of 2 years mountains were moved but alas that wasn't enough, and funds ran out before we reached a version stable enough that we could run our application on it. In some ways we got pretty close, in others we were still miles away from completion (most notably, the network core and the actual app). Precious time was spent optimizing things that did not need optimization and most of the lessons start-ups learn were re-learned, sometimes (very unfortunately) against better judgement.
I've been asked to look at salvaging this team/project/company and am working together with one of the founders to get things back on their feet in some form, so it is a very delicate situation.
Let me talk it over with the rest of the guys involved and see if they are willing to let me write it up, I wouldn't do it without their buy-in. One potential snag here is that there is still some lingering hope we can re-boot this thing on an existing platform side-stepping the bulk of the development and just concentrating on the app portion (which was my initial preference anyway so I don't mind that).
Well, this one is technical in many ways and there really is an interesting angle there when you remove all the other stuff. That's still going to be a very harsh thing to see black-and-white in public rather than with context in private.
The tech part essentially boils down to 'the right tool for the right job' and don't try to fit square pegs in round holes when you're on a deadline.
The list of 'lessons learned' is rather longer than that ;)
Obviously, you have to learn Common Lisp if you're thinking long-term - the one language that people will still be using when all the ones you've named will be history!
That takes the fun out of it. I do think that one can safely bet on scala or go and have fun.
If you have the right architecture you can be as polyglot as you'd like. It's just risky from a maintenance standpoint.