Hacker News Reader

Comment by codecurve | Hacker News Reader

It feels like the author made the jump straight from PHP to Go without spending much time actually using Node or Ruby and he's subsequently shocked at how much better modern languages are when contrasted to PHP.

Many of these "solved problems" have also been solved with the other languages, albeit not always at the surface level. For Node specifically:

WebSockets -> SockJS, Socket/Engine.io

Concurrency -> Generator Functions

Testing -> import assert from 'assert' and npm test

Syntax -> Some great improvements with ES6 and solid styleguides (airbnb, standard) + eslint as an autoformatter

The major win here for Go is that as a new platform it was designed with simplicity in mind. These features are probably easier to pick up in Go than any of the alternatives, which is great. However, don't make the mistake of thinking that Go is the first language to solve these problems.

View on HN

Author here, I have used both Node and Ruby fairly extensibly. I think I touched upon Ruby's performance issues in the post. That's why I don't consider Ruby a solid solution. Also, as far as I'm aware, Ruby doesn't have built in concurrency like Go does. Yes, Nodejs is close to being concurrent, but it really doesn't hold a candle to Go. Yes Node has socket.io, something I've used a lot and love. But Go has all of those features natively.

What about Java and .NET stacks? They do everything that Go does and more.

We are also web developers on those stacks.

I don't know about .NET, but Java definitely suffers from the enterprise verbosity problem (no it still hasn't gone away).

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.

> 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.

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.

I recently rewrote one of our services in Go and there was a SQL interface in the standard library with backends for all SQL databases that matter. I don't remember if the backend we used (for PG) was from the community or the standard library, but that's rather inconsequential.

For our customers that means Oracle, SQL Server, Informix, DB2,... from the database vendors themselves.

Not community projects that kind of work.

For the last 3 months, Groovy has been officially known as "Apache Groovy".

with play-ws it's even

    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.

Nothing prevents you from writing an entirely new Java library.

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).

Actually it is easier to write generic code in Java than in Go.

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.

Either you make a method of it and then you can call it in 1 line, or you can use some libraries like OkHttp from square which will let you do that with only 5 indented lines, not 20+.

    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.

.net might be good I have not used that. But as Java developer I do find this quote apt. 'I had a problem so I start using Java now I have 2 problems.'

Sorry, your definition of "concurrent" is all over the place.

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.

> Ruby doesn't have built in concurrency like Go does

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.

> > Ruby doesn't have built in concurrency like Go does

> Seriously. Pretty much all languages have support for concurrency via threads.

You missed the most important point: like Go does

Have you tried Elixir/Phoenix framework?

I looked at it a while back. Even played around with Elixir, which I liked as a language quite a lot. But the deployment and configuration for Elixir/Phoenix/Ecto was pretty horrendous. Lots of dependencies, lots of tweaking, I think even NPM was required too?!

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.

Using exrm its a very simple setup. You get a deployable tar file which gives you the ability to migrate up and down as well. The only issue i have is wrt to running migrations on deploy server. Go is very good for services. But i didn't find any mature libraries like Phoenix.

Exrm looks good for updating an already established application. Doesn't look like it does anything for the initial setup and configuration of a new system though.

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.

> 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.

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

Clearly I'm not as up to speed as I might be. How do I avoid installing and configuring Erlang, Elixir, Phoenix, etc. on each machine I want to "paste" to? How do I bundle all these into one extract and go package?

The tar contains erlang runtime. It has config file as well which can edited to change the setting.

Then definitely more interesting than my cursory look. I don't see any mention of bundling the runtime but I'll take your word and dig around a bit more. Thanks for the info.

If its the same architecture then you can copy the tar file to another system and run it. Its the same for Go apps except you get a binary. I do not want to recreate all the structure( I basically do web apps). Phoenix provides good defaults. If it was few lines of code then Go is fine, for larger project i prefer Phoenix( prefer might not be the right word since i don't have elixir prod apps while i do have Go apps)

Not yet, I've got as far as reading the Elixir docs start to back, I really enjoyed what I saw, I'm yet to have a play around with it though. I'm hoping to this weekend :)

I wrote some notes on my own "weekend with Elixir"[1] - literally - maybe you'll find something helpful there.

[1] https://klibert.pl/posts/weekend_with_elixir.html

This is great! Thanks, this has inspired me!

Did you try jruby? Makes things much faster.

In my experience when a project makes the decision to switch to jRuby it's time to think about breaking parts of it into another language, you end up having to write Java in Ruby and subjecting yourself to the worst of both.

> he's subsequently shocked at how much better modern languages are when contrasted to PHP

yeah no, please compare node/ruby whatever to modern PHP and not some ancient versions you used some time ago. Modern PHP is very much up there.

Also mention Laravel.

You have made a really good research on authors background. His previous post really support your point dude.

You sound sarcastic. I'm not sure what you're trying to say.

At a glance his previous articles seem to be about Go and PHP (with a little bit of shell scripting) as well, so GP's point seems to stand.

Reply on news.ycombinator.com