> I was under impression that it's more of a backend language, tailored to the needs of backend devs
For one thing it could mean only coding in one language on both client and server side. If three is little friction between the language and the needs of client-side code then the drop in context switch need between the two could be worth it to some people.
Much like using Javascript server-side when most considered it a client-side only language (an opinion that is pretty much dying away now - the remaining people who don't like the idea of it server-side don't like it client side either).
Or any other language. I'm sure if someone wanted it enough a client-side implementations of PHP and Perl would turn up so you could use those languages in the browser. We might think it a bad idea, but for people who use those languages day-in-day-out elsewhere there is a possibility it might make some sort of sense.
My point is that the "same language both sides" argument is relevant to any language, be the language Go, Javascript, or anything else, and be the client a native app on a mobile platform or running in a browser instance.
If there are people who want to use Go client-side, why not let them? Just because it doesn't make sense to our workflows, doesn't mean it isn't the right tool for somebody else's job.
For one thing it could mean only coding in one language on both client and server side. If three is little friction between the language and the needs of client-side code then the drop in context switch need between the two could be worth it to some people.
Much like using Javascript server-side when most considered it a client-side only language (an opinion that is pretty much dying away now - the remaining people who don't like the idea of it server-side don't like it client side either).