Go, or Ruby or ExpressJS for an API?
I'm building out an API and I would like to know your thoughts on the benefits and pitfalls of the three language options. I'm a Ruby Pro but I am considering both express and Go for my API.
I would say neither Go or Node would be a bad choice, each having their tradeoffs. Node honestly is very performant overall given the time in which it takes a developer to code, test and deploy (tradeoffs). Also IMO Node has a little more available in terms of examples and people that have already hit the issues ahead of you. So if time to completion is important, it might be faster for that purpose alone. Then if you find a hot path, work to optimize it etc.
For what it is worth too, I hear people complain about Node occasionally and it is usually when they are trying to do longer running tasks, like huge sorts etc. Node is not a good candidate for work that blocks the event loop for long periods, there are better tools for that as you probably already know. The other complaints I hear/see often are when people choose the wrong 3rd party plugins to base their systems on. npm makes it easy to install almost any module, and sometimes that low barrier makes for easy but less than stellar choices; its like anything research the module first and try real scenarios as a POC before committing.
Also there are other frameworks other than Express for Node, for example you can check out HAPI which some people have switched to for RESTful API work.
You have to write more actual code than in Rails (or even ASP MVC), so it takes longer to develop, but it's much more satisfying.
I'm not 'web-scale' so the speed differences didn't actually matter that much. I didn't optimise for speed and the benchmarks were still impressively exceeding our requirements.
The standard library is amazing in places, but there are some libraries (gorilla in particular) that are almost obligatory.
If you have to write 2 API's you'll re-use a lot of code... you've effectively rolled your own API framework.
If your editor can handle snippets, make one for "if err != nil{" since that's a good 25% of any go program it seems ;)
Go is deep; the tools are deceptively simple and amazingly powerful. I refactored a lot as I went along and discovered better, more elegant ways to do things I'd brute-forced on the first iteration.
It was fun! Go is a really lovely language to code in.
If you can afford some extra time to learn a new framework then both Go or Express/Node.js are great options that would enhance your skill set.
Node.js and Go are both growing quickly in popularity. They're much faster on the execution side than Ruby and provide additional optimization opportunities via the ability to query more than one external resource simultaneously and combine the results into your API's response.
If you do decide to go with Node.js or Go, Node.js is currently the more popular of the two. You're more likely to be able to land a job or freelancing gig with Node.js skills today, whereas you're more able to contribute something meaningful to the Go ecosystem by getting into it now.
Personally I prefer coding in Go, but most of my client's request Node.js.
http://jaxbot.me/articles/benchmarks_nodejs_vs_go_vs_php_3_1...
Go if you need performance, but slower development time.
ExpressJS/Node for neither. Just kidding, it might be sort of like a combination of the two, moderate development and moderate performance. Though, this sort of makes it's usefulness moot for me, but that's /just/ me. I either the fastest development time, or fastest application. Both usually ends in a clusterf*ck of some kind (IMHO).
Personally, though, I wouldn't use any of the above except Ruby and would use something JVM based. Play! is a mature framework, it's fast, and is easy to use/deploy. It also comes in both Scala and Java varieties.
I've used everything mentioned but Go, and the JVM keeps coming back to haunt me because it's fast as hell and has TONS of libs.
Go's not quite mature, and it shows at times. For example, if the tcp connection underlying your database connection dies, it won't reconnect automatically.
The standard library is neat; net/http is friendly and easy to use but unless you want to spend half your time munging request.URL.Path with regexes you'll want to use a different mux / router from the standard library - there are many good ones available.
Channels make realtime (ie, websockets) quite simple, and the type system means you can iterate quickly without so much fear of introducing bugs.
I can't speak much for the performance; we haven't tested it under much load yet.
As mentioned in another comment, yes, most Go database drivers do not reconnect for you. It's an easy enough pattern to code for yourself. Some PHP & JDBC adapters don't either.
Memory usage was under 10MB and Valve eventually called us asking to throttle our calls, as their servers couldn't keep up and exhibited race conditions. Delays needed to be added to our job queues.
I've used Sails.js (built on top of Express.js) and can't say it's anywhere near Rails yet.
Also, Node maybe be the "wrong" tool for building APIs. By wrong I mean it's not its particular strength.
In the past, I build APIs using nodeJS with restify. Here's a boilerplate made by a good friend of mine: https://github.com/dominiklessel/restify-api-boilerplate