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.
Comments
But you can do the same thing with Java (or Scala or Kotlin).
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.
Java, Scala, and Kotlin aren't the only options for "one language on the client and the server."
You could also use C++, C#, JavaScript, Lua, Objective-C, Python, Ruby, and more. See http://www.mobilechameleon.com/
Some people just fall into using one language and want to use that language for everything. Why not let them?