> And I question this litmus test of using a junior dev anyway.
As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard.
[1] Sometimes literally a junior too.
[2] There's a few things I think might trip up someone brand new to Go.
Junior as in non-expert in the field. Using simplistic languages means optimizing for quickly pumping out code (at the expense of maintainability in the case of golang, as I've personally experienced at an employer that has one of the largest golang setups on the planet). Not to mention that golang comes with its own set of gotcha's and idiosyncrasies that need to be understood, especially in more involved programs.
There's a good middle ground that can and has been achieved by other languages.
What does this actually mean? They are both programming languages made for solving general problems, what makes the comparison inappropriate? I've used both and pretty much all of their cousins, so I'm confused why you would think they aren't comparable.
The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.
As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard.
[1] Sometimes literally a junior too.
[2] There's a few things I think might trip up someone brand new to Go.
[3] Looking at you, Perl and Ruby.