I don't understand. How can it be an illusion of productivity when it actually produces something that's very easy to see?

He is saying what is very easy to see in certain contexts is not transferrable to the abstract. Go can be shockingly productive at certain tasks, but it also falls flat on its face at others. If you take your limited experience with Go (or whatever; this applies to all tools) where you found it to be highly productive and then conclude that it is always productive and therefore a tool you can use in all situations, you are bound to encounter negative productivity when you have a different problem to solve.

Need to write, say, a network service? Go can no doubt give just about anything else a productivity run for their money. Need to solve a machine learning problem? ... Good luck. It can be done, of course, but you're quite likely in for a whole lot of extra work not needed in other ecosystems, destroying any semblance of productivity.

In other words, the comment is a thinly veiled "use the right tool for the job".

Productivity is the sum of the aggregate output not just getting started.

If you're familiar with a tool, you might be able to "get something" a lot quicker with it than learn to use the correct tool, but on the long term, the correct tool pays off better.

Very few languages are good at _everything_.

But what I do 95% of the time is backend services with APIs and CLI tooling, for both it's amazing.

For GUIs it's hit and miss. There are some attempts at tooling, but they all feel a bit off to me. But Rust the same issue, as does C#.

We need a modern Visual Basic again =)

I think well-written and engineered Python can do this (given the scripting/easy to call other languages bit), but there are still going to be bits where you're going to be fighting uphill (whether that's because the area is actively pushing against their preferred option, or where a scripting tool is inappropriate).