[arturadib]

It's going to be a tough sale for Google to convince people to adopt Go for their web apps when Node.js is taking over that scene. With Node I get the best of two worlds: high concurrency and speed -- presumably the top two selling points for using Go with web apps -- without having to teach myself yet another programming paradigm. Everyone and their mother knows some Javascript; good luck hiring help for your Go-based startup.

IMHO, Google could be riding a much bigger wave right now...

[bjg]

While I agree that go on appengine might not take off, in no way is node.js "taking over that scene". If by scene you mean the "web app" scene. Just because node.js articles are constantly blowing up hn, reddit does not necessarily correspond to real world deployments of node.js apps.

An admittedly hastily prepared google trends graph: http://www.google.com/trends?q=node.js%2C+python+django%2C+r...

I am a node fan, I subscribe to the node-dev list and have worked on a few applications my self. However I am in no way delusional about the current blog popularity vs actual projects deploying with it.

Also you state that you are able to gain the same concurrency and speed with node that you are with Go. May I ask how you achieve this? Go usually comparable to C code in terms of performance [1]. Go also has amazing concurrency tools for efficient communication between two concurrent goroutines, for example the channel interface[2]. To my knowledge their is no way to run concurrent node processes. You can launch multiple instances of the same program but their is no way to let them communicate without sending data over a socket. You can of course use a reverse proxy to present a single entry point in which multiple node backends can take requests. However you can not claim this as concurrency in the same sense that is available with go.

[1] http://golang.org/doc/go_faq.html#Performance

[2] http://golang.org/doc/effective_go.html#concurrency

[rgbrgb]

Go looks really nice and I'd really like to learn it especially if I can make a web app or something with it this summer.

Is there something comparable to npm or pip for go? I've seen a few go micro web frameworks but I'd really like to see a list of things like database adapters and the like which have been produced so far. The thing I find amazing about node is just how many great modules have been put out in it's short lifespan (https://github.com/joyent/node/wiki/modules). I suppose Go is a brand new language though.

Thanks!

[bjg]

Go has a surprisingly large package list: http://godashboard.appspot.com/project

Like pip or npm, their is goinstall http://golang.org/cmd/goinstall/

[rgbrgb]

Amazing, thanks!

[robfig]

But with Go can you write your client code and your server code in the same language?

[KirinDave]

People keep touting this, but the actual number of cases where you really want this is actually pretty limited.

[rjurney]

With robust server-side javascript... its not hard to see the application of this. It is easier to generate executable javascript for the client on the server in javascript itself. Certainly in Web2+ you want this for increasingly dynamic behavior?

[KirinDave]

I do want more dynamism, but I don't see why you should be passing and executing arbitrary code from a source you can only verify with the greatest of difficulty. And having executable code be your communications protocol seems like an absolute nightmare if anything goes wrong. Hell, just versioning it will be hard. It might work for some simple demo apps, but I seriously question the wisdom of such an approach with a team who's size is >1.

Why not pass Json, and write your client code. It's not like Node is so expressive that it's a big win on server side code (especially with the flood of great altjvm & altclr languages these days).

[edsrzf]

Maybe some day: http://code.google.com/p/go/issues/detail?id=498

(Native Client is also a possibility.)

[robfig]

Sorry, this was actually a tongue-in-cheek comment. :)

[rjurney]

I'd like to see more server-side XLST.

[strlen]

> good luck hiring help for your Go-based startup.

If you're unable or unwilling to become fluent in a new language (especially Go, which isn't that difficult to learn), there is no way I'd hire you to program in any language.

Programming ability is multi-dimensional: not everyone is a top-notch as programming language geek AND an algorist AND an architect/designer AND systems hacker. Nonetheless, a programmer should have some aptitude in each of these areas, even if they shine particularly in only one.

A more eloquent summary of this thesis can be found at:

https://twitter.com/#!/moonpolysoft/status/19553333429

[stephth]

With Node I get the best of two worlds: high concurrency and speed

With Node you still need to write in an event-based style, which is something devs often complain about working with Node.js.

"With goroutines and channels, you can say 'I'm going to send a message to another goroutine or wait for a message from another goroutine', but you don't have to actually leave the function you're in to do that," Gerrand says. "That lets you write asynchronous code in a synchronous style. As people, we're much better suited to writing about things in a synchronous style."

from http://www.theregister.co.uk/2011/05/05/google_go/page4.html

[jerf]

It's going beyond cute and getting into downright tedious that the Node.js crew think they have some sort of unique lock on concurrency and speed, when instead they are late to the party with an inferior implementation. This meme needs to die. I'd take Go in a heartbeat over Node.js for anything remotely non-trivial.