It's not that they are bad languages, it's that they are the ones that everyone knows, so I don't believe that there are open positions on those languages that nobody wants, unless the money is obscenely low (which it often is).
Man, how things change. I remember times when most developers would derisively laugh off Python's indentation.
Back in 2006, Python jobs were so few and far between, you'd struggle to get paid to work with it. 10 years later, "everybody" works with it, so apparently you struggle to get paid a decent amount.
Why can't I ever find a niche I like and paying well? :(
I've actually found it pretty hard to find regular work focused on doing FP. My last job was Erlang when I started, but pivoted to Go because of a lack of Erlang developers. My last two jobs before that were mixes of C and Haskell, but only because I was given the lattitude to select haskell. This time around when I was interviewing I was trying to find something that would let me focus on FP, but the best I could find were jobs that ostensibly wanted to hire Clojure and Scala devs, but really 90% of the job would be maintaining a bunch of legacy enterprise architecturey Java with just enough FP to try to attract people into the positions.
Become a sysadmin that writes tools (which is more like old-school system
programmer, the one who wrote grep and syslog and init and bash and awk).
Since you're nominally a sysadmin, nobody will look at your workbench to check
if you're using "kosher" languages, so you're free to use whatever makes sense
to solve a problem (hint: not always a functional language).
Been there, done that, been happy with the approach.
I know a couple of people who do something like that. I don't think it would work well for me though, since I had to resign from my current job because although it was a developer role there was a good bit of sysadmin required and I just find that work extremely unrewarding.
Go vs. Erlang feels like a pretty difficult comparison to make because they feel entirely different. Erlang isn't a bad language, but it never felt like more than a very flexible DSL to me. If you look at OTP with a critical eye, it's actually not much more than a lot of tooling on top of a state monad; and my limited experience with using the language professional makes me feel like you're buying a lot of code complexity and you need a very strong group of people with a lot of erlang experience to make that complexity pay off. Some of the process management and hot code updates and such that used to be really beneficial are less beneficial now that we have so many other solutions to managing containers and microservices, and the language itself, while functional, never really felt to me like it was achieving the power and expressiveness of other functional languages I've used. A lot of that seems cultural; I wrote a little toy monadic library in Erlang when I was trying to help teach some coworkers about ideas from other functional languages and how we could use them in our codebase (https://github.com/rebeccaskinner/erl_m) but I don't see a lot of libraries like that coming out of the wider Erlang community- there seems to be a much stronger focus on solving a single concrete problem than on making development in the language better overall.
As for Go, I do like the language- well enough that I took another job where I'll be mostly using it. I can't quite shake the feeling that some of the syntactical and stylistic choices were made more to be different than because they are better, but I can move past them. I think goroutines and channels have a lot of potential as atoms of concurrency for building models going forward, and I think it's nice to see a language gaining popularity that is focused on being small (in the sense of the size of the spec) and simple (in terms of feature interactions). I don't think a lot of it's potential has been realized yet, and I hope that we can take some of the lessons learned from other languages, e.g. Conduits and FRP from Haskell. For right now I've seen enough cases of people introducing threading errors and problems introduced by the user of pointers that I think it pays to be wary of third party libraries.
