Hacker News new | comments | show | ask | jobs | submit login

If I was starting from scratch today I'd use Go. Go makes writing fast, scalable and reliable servers as easy as it is possible to make it. At least that is my experience.

I started out writing CGIs and servers in C many years ago and have experimented with Perl, Python, PHP, Ruby, NodeJS and Go since then.

Go has a syntax that is instantly familiar and simple to master. Go's concurrency paradigms are simple to understand and easy to use. Go's compiler is fast and clear. If a Go program compiles it nearly always runs. Go's built-in library has most things you need to write HTTP-based servers.

If you use Go naively you will almost certainly be using Go correctly: your server will be fast and efficient. This is not the case with NodeJS. Writing fast, efficient NodeJS code is hard. Maintaining fast, efficient NodeJS code is even harder.

On the down side - while Go don't suffer from 'callback hell' but it does have a tendency towards 'cast soup' - this makes working with JSON a little trickier than it should.

Aside from the main programming language I would also look at:

* JSON API-first driven development

* Redis

* NodeJS's plethora of web-centric code management tools & compilers: SCSS, RequireJS, Grunt etc

* Single-page javascript App technology: Ember, Angular etc

* Docker.io


* Camlistore

These (with Go) are the main technologies I'd use to build a large web infrastructure.

I've done a couple projects with Go now and really like it, but it does have a big weakness as far as backend -- models and and the tools to make a good model abstraction layer. This may be a personal opinion problem, so I'd like to hear what other people think of it. I personally find the tools for interacting with datastores particularly weak. Their sql package for example was way too simple for me.

I've heard good things about the mongodb package and interface, but I haven't had a reason to use mongo.

So really if you use Go for your server side, you'll get a lot of nice benefits, listed by sambeau, but just be aware, you might have to tussle to find the right fit of backend tools, and you will likely have to make your own Model abstraction. This might not be a downside though, as I know a lot of engineers will build (or rebuild) the model layer no matter the framework.

If you're looking for an ORM-like thing, check out gorp (https://github.com/coopernurse/gorp). I find abstracts interaction with datastores quite idiomatically.

I find gorp with Revel (http://robfig.github.io/revel/) makes for a powerful and performant backend. I just wish Revel had better testing integration.

Node doesn't suffer from callback hell if you're an adequate javascript developer. Named functions?

Or how about a class which you pass methods to your callback functions and bind them to the instance properly.

You never need to nest a callback if you know how to work with prototypical inheritance.

So, clearly, I'm not 'an adequate javascript developer'.

Luckily an inadequate javascript developer can write naive code in Go that reads from disk or writes to a socket without worrying about needing "a class which you pass methods to your callback functions and bind them to the instance properly" or "prototypical inheritance".

You can just call a function and use the result.

you still need to write callbacks,wether they are named or not, that's the problem. Go deals with concurrency a much nicer way. 10 asyncs operations in a row are still 10 functions you'll need to write in javascript.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact