It's widely used in industry and isn't going anywhere.
All the people freaking out about performance didn’t realize that even in the Python days, half of our datacenters pretty much sat idle or severely underutilized. Computing is dirt cheap as long as you’re not renting a 15-year-old CPU from a Cloud Provider for 100x markup. The other thing is that engineers would frequently build things that were just wasteful or unnecessary, and sure, Go sped things up, but you could have changed the design instead of the language.
But Go isn't a silver bullet. It's another tool in the toolbox and sometimes it makes sense to reach for Python, or Kotlin, or Swift, etc. But choosing Python when you should've chosen Rust / Go / D is a tough design decision to quickly come back from.
Actually it came out about 10 years ago, in one way or another: https://go.dev/doc/devel/release So it largely depends on what timescales you're comfortable with - some people switch stacks or learn new tech every 3-5 years, for others this cycle is slower or faster, also depending on the stuff you're working with.
I'd say that web dev moves quickly, embedded moves more slowly, the rest is somewhere in the middle for the most part, maybe AI/ML and certain DevOps aspects rival web dev speeds of innovation/churn.
> I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).
Perhaps, i think languages like Rust will be pretty widespread, both in the Linux kernel, as well as many tools and whatnot, albeit in a different and perhaps more conservative fashion than currently (the "rewrite everything in Rust" craze). In contrast, most of the modern web based SaaS solutions will be dead, most certainly the majority of Kubernetes tooling out there.
Go might just be boring and useful enough to stick around and join the dreadful bunch of languages used in maintaining legacy code. It's funny, though, because while the languages themselves are more usable than they were 10 years ago, people's sentiments (including mine) are largely influenced by how many bad codebases they have to maintain: https://earthly.dev/blog/brown-green-language/
On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die.
Isn't that Perl?
Some of the nicer Perl software that I use currently is BackupPPC, which has been pretty solid despite the slightly subpar UI: https://github.com/backuppc/backuppc
And another interesting piece that I can think of was RemoteBox, which was pretty niche but still worked nicely: https://remotebox.knobgoblin.org.uk/?page=about
From the more popular packages, one should also mention exiftool, which was written in Perl: https://github.com/exiftool/exiftool
Probably also a lot of other pieces of software, though it doesn't seem like there's much of a large/active community around Perl, for example, have a look at: https://github.com/trending/perl?since=monthly and then compare it to something like: https://github.com/trending/go?since=monthly
In regards to other contenders, I think FreePascal/Lazarus should also be mentioned, since they're pretty stable, capable and perhaps some of the better ways to write desktop software!
Actually, that repo has lists like this for most languages: https://github.com/EvanLi/Github-Ranking
Hmm all the languages you listed have certain niches that I think will likely remain alive in the next 20 years, except I don't think Perl deserves this spot. I think anything Perl is a great fit at, Python will also be a great fit and (subjectively) python code ends up being strictly more readable than perl.
I would guess PHP also has a similar relationship to Python but the effect, I believe, is a lot milder as PHP shops seem to be more decisive about sticking with PHP. All evidence anecdotal of course.