We are also web developers on those stacks.
I mean, tell me the equivalent Java code to this:
resp, err := http.Post("http://example.com/upload", "image/jpeg", &buf)
I think that would be about 20 lines in Java. You've got to make a `HttpUrlConnection`, then call `setDoInput(true)` (or is that `setDoOutput(true)`), wrap it in a `try`, etc. etc. etc.Go's standard library is amazing.
Nothing prevents you to wrap those 20 lines in a generic method.
Also there are other options in Clojure, Scala, Kotlin, Groovy besides pure JDK API calls. Here Scala style, easy to mimic in Java 8
val result = http.postData("http://example.comupload").header("Content-Type", "image/jpeg").responseCode
> Go's standard library is amazing.So amazing that is doesn't have proper database drivers for the SQL databases that matter.
Not community projects that kind of work.
ws.url("http://example.comupload").withHeaders("Content-Type" -> "image/jpeg").post()
Also this is non blocking, while the go code will bock, by default. there is even akka-http now which could be wrapped really great which is streamed by default, even better.The point is Go's library already has all the nice convenience methods. With Java I would be endlessly writing them myself, and even then they wouldn't be as good as Go's because they wouldn't be standard (no help on StackOverflow for example).
Also many Java bashers in the Go community seem to be unaware of what is delivered in the JDK.
When I used to daily read gonuts, many weren't even aware that since Java 6, there is a similar infrastructure for HTTP(S), no need for third party servers.
Request request = new Request.Builder()
.url("http://example.com/upload")
.post(RequestBody.create(IMAGE_JPEG, file)
.build();
Response response = new OkHttpClient().newCall(request).execute();
But yes Go's standard library is cool, but Java's ecosystem is too, and larger.Ruby doesn't have "built in concurrency"? Ruby has fully native threads; it just has the GIL that blocks for IO (but you could use jRuby). It gives you several options for message passing. You also have the extremely under-rated dRuby system. Not to mention the whole EventMachine world.
Node is "close" to concurrent? It's god damn single-threaded! At the very least it's possible to spawn multiple processes and communicate over a Unix socket, good luck doing something like that with PHP. What does socket.io have to do with anything?
Sorry man, I'm hearing a lot of cargo cult opinions and precious little data to back it up.
Seriously. Pretty much all languages have support for concurrency via threads. Ruby even have the equivalent of channels since a decade: http://ruby-doc.org/core-2.2.0/Queue.html
Now if you meant to talk about the GIL, well it prevent parallelism only for purely CPU bound tasks. And in the context of a web app, if I have a CPU bound tasks that I can just fire and forget, I don't want to execute it on my frontend server anyway.
> Seriously. Pretty much all languages have support for concurrency via threads.
You missed the most important point: like Go does
I do have fun bashing Go, but I also use it. It's too practical not to. And the Go team, above all other of the latest wave of language that are ready for production, got that 100% right. I just can't overstate how simple Go makes setup, deployment, and updates. And how complex Elixir is in comparison.
I wish Elixir et al. could have a zero dependency, zero external configuration, and single/xcopy file deployment too.
For me, the ultimate test is can I copy my application to a flash drive, walk it to a new clean system, and "paste" it to that new system. Go really does let me do that.
> But i didn't find any mature libraries like Phoenix.
Yup. But then I tend not to need larger frameworks with my Go apps. Like you allude to, Go apps tend to be less monolithic.
That used to be the case for erlang deployments that looked pretty similar, and Exrm looks like it does the same thing:
https://hexdocs.pm/exrm/extra-deployment.html
There are five stages to creating and deploying a first release. The first is just generating it, the next three are for moving the release to a new place and the third is just decompressing it.
Live upgrades/downgrades seem pretty similar: https://hexdocs.pm/exrm/extra-upgrades-and-downgrades.html