[matthewmacleod]

I don't think that's a reasonable view.

The point is that articles about rebuilding entire systems in different languages conflate two things — an architecture change, and a language changes.

This often results in the sort of appraisal you see here – 'Go is better for us than Ruby, because we completely rebuilt a system and it's now better'. That's got some value, but it's frustrating to see it used as something of an absolute metric regarding the suitability of a language when it's conflated by the far more important architectural changes.

So I think your view that there are a bunch of developers who are afraid of the future is a little shallow; rather I suspect there are a bunch of developers who saw exactly the same sort of thing happen when Ruby was becoming popular, and realise that extracting helpful data when there's an ongoing fad ('we're jumping from X to Go') is rather difficult.

[jbergens]

But a change of language might bring you more tools, for example to handle thread-pools or process pools (service worker pools). Some of these things might be much easier to do in Go (or Java or C#) than in Ruby and if that part was a reason the new version works better the language change did help. I am no saying it was impossible to improve performance with Ruby but they might believe it was easier with Go. I still think a monolith app can be more performant than micro services in a lot of situations but you might have to use things like thread pools/channels.