[jstx1]

Your question somehow implies that you can learn one language, maybe both if you really stretch yourself, and then that's it - you're locked in for 20 years. In reality, the effort that it takes isn't that much, you need to stay fresh on new tools anyway and so much will change in those years (you, the languages, the industry) that it's pointless to make such long term predictions and plans.

Personally, I would pick Go because there are more job opportunities with it right now. I also don't see the value proposition of Rust over Go at that level of abstraction (backend, cloud microservices). There are subjective elements to this too - I like that Go is a fairly simple get-things-done tool and is less cult-like than Rust.

But I don't think that it takes that much effort to switch languages, especially if you stay in the same problem domain. And I don't think that choosing a language is that big of a deal if you're already choosing between two good options.

[potta_coffee]

Anecdotally, I invested in Go and in IAC tools (Terraform etc). I've been building infrastructure, pipelines, as well as cloud-related tools for developers, and this niche has worked out for me really well. By that I mean, I doubled my income after a year of focus in this direction, after spending years doing more traditional web development (Python / Flask / Javascript / React / etc).

[nsonha]

Interested, what is your job title now and what is the challenges looking for an infrastructure job with only web dev experience in your CV. How did you start doing platform/infrastructure work? Was it picking them up at work or OSS/side project?

[potta_coffee]

I was working at smaller companies and I crossed over into cloud and infrastructure incrementally by necessity. So at one company, I was managing a team of developers who were all decent at web development, but the company mandated that we take a number of disparate products they'd bought from other companies, running on mostly on-location and migrate all to the cloud. Since there weren't any cloud engineers around, this work fell to me.

After getting some hands-on experience with this type of work, I found a job at a managed services company that had lots of AWS expertise, but really didn't have any good programmers working for them. Since the company wasn't really a software company, they neglected programming skills in the interview process, but then found themselves in need of more development horsepower. While there, I ended up building internal tools and APIs that smoothed over some gaps not covered by the myriad 3rd party solutions they were cobbling together, and also build APIs over some janky ad-hoc Lambda based processes they'd built.

After a year at that company, I was able to land a better gig at a company as a "senior cloud engineer". What clinched this role for me was also programming ability. It seems like a lot of "cloud" teams are composed of former operations guys that seem to hit a brick wall when they come to certain tasks, and I'm pretty good at bridging that gap, and that's how I sell myself.

[nfgoto]

I just don't want to keep switching languages every two years.

The goal is to specialize in a purposely limited number of stuff that keeps its value long term.

[jstx1]

I would plan for 3-5 years ahead depending on your interests and what you like to do, instead of trying to minimise the switching of languages or making guesses about decades in the future.