I think there's a lot of truth to this, but I'm going to make an additional suggestion that I'll readily admit is biased by my own feelings:
I think Go is in a honeymoon phase and people will hate it in 10 years; I think Rust will continue to be liked even when it's a legacy language (perhaps no language can continue being loved once it becomes "brown", but I think Rust will be a lot less dreaded than others).
Go, like Ruby (mentioned at the end of the article), is optimized for building. You can do things quickly and easily with minimal ceremony. Some people love that. But that's exactly the trait that's starting to weigh on Ruby, and it's exactly the trait that has put PHP and Perl in the "dread" category over time (remember when people were in love with those?).
Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.
This kind of forethought is what makes a language that survives the honeymoon phase.
When Ruby was "hot", it was bringing a lot of new things to the table, things new developers take for granted now.
If you start a new project in typescript, or even C#, you'll get almost all of the things that made Ruby great in 2006.
When I introduce a new developer to Ruby, all I've got to argue in favour of it is that it's a beautifully designed and powerfully expressive language with a library ecosystem chock full of de-facto standardised gems. Relatively vague things, and any newbie can hit me back with its downsides: mediocre performance, no type definitions, and no evented I/O baked into the language.
I do dread the day that I can't start a new project in Ruby, simply because my hiring pool would turn into a mire of people dreading to work on it.
Actually no.
The way Ruby looks like, it was done in Smalltalk first, with performance, good graphical tooling and developer experience.
If you mean Rails, Zope, AOLServer and Vignette did it first.
I'm sorry, no. Everyone knows that before Rails there were only three ways to make a web application. You could do it in either PHP, in Java servlets or in ASP.Net. Ok and maybe ColdFusion MX.
Only for souls that only started to do web development after 2002, and never learned about what the world was about between 1994 and 2002.
I can gladly educate you on how Rails did not improve on the stacks already available, rather bring the concepts to a younger generation that never learned about them in first place, starting with ActiveRecord.
Could you go back and tell 17yr old me know that there's something better than ASP.Net out there? I was doing .Net trying to dodge the Microsoft stack running early versions of Mono and everything, anything to dodge PHP and Java.
I'll gladly receive that education, I have a hard time believing any of those frameworks are as sophisticated today as Rails 2.0 was back in the day.
I could tell how they looked like from startup rooms in little offices spaces in Lisbon back in the early days of .com wave in late 90's, how AOLServer influenced the creation of Intervento's Safelayer framework, or how it got us to be approached by MSFT Portugal for adapting the same ideas to then still alpha version of .NET, however I am the right person to fully tell the story, better let that to the key persons, in case they feel like jumping in.
In any case, here is some education material for yourself,
https://zope.readthedocs.io/en/latest/zopebook/index.html
https://docs.huihoo.com/aolserver/intro/features.html