Author has either been making some ridiculously inappropriate system apps or is about to start making equally questionable web apps.
Obviously languages can serve multiple purposes but the intended uses of these have almost no overlap.
Obviously languages can serve multiple purposes but the intended uses of these have almost no overlap.
Languages specialize. PHP is suited for the web because it is a dynamic language, stuff is compiled right when it is accessed, and there is no memory sharing between requests.
Go, C, C++, etc. are static languages, stuff needs to be recompiled for even a minor change, and of course, memory is shared for each request.
And that's just the tip of the iceberg.
Obviously you can bring all functionality that the web demands to Go. A jit compiler might help, maybe some loose typing, a few other widgets ... and then, guess what? You turned Go into PHP.
For each job, a proper tool.
Not with Go. Go compiles super fast.
just like it was being done in game development for decades already, it's not like web app is much different from computer game
I don't think this is really a problem. Although dynamic typing vs strong typing advantages/disadvantages are a whole 'nother argument, the reason you might choose (say) Python over Clojure for a web app is the ecosystem (libraries, frameworks, deployment), performance (is this a concern for your design?), the syntax (do you like it?) and tools support (IDE's, etc.).
> Obviously you can bring all functionality that the web demands to Go. A jit compiler might help, maybe some loose typing, a few other widgets ... and then, guess what? You turned Go into PHP.
You could say the same about Ruby or Python. Both built up a lot of web-centric libraries and packages. But neither have "turned into" PHP.
Yes, some languages reduce the barrier to entry for certain tasks. But that doesn't mean other languages are a bad choice; they likely have other benefits worth considering.
memory is shared for each request
What does this even mean? Something like an Apache module (as an example in C) may or may not share memory depending on how it is written, but there is nothing that means it must share memory.
All sensible web programming environments have a stateless programming model (if that is what you meant). Some add state on top of that using sessions etc, but that can be in any language.
All sensible web programming environments have a stateless programming model
I don't consider this a problem in Go, because the good module system and scoping rules mean that global state is explicit and obvious, and a good concurrency model means that accessing global state can be done safely. Global state can be useful and performant, so I'm glad Go lets you take advantage of it, but it might rule it out as a "sensible web programming environment" by your definition.