[pearkes]

What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server.

I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular Python framework at 18,945[2] (3.1 ms) is trivial when you look at the bigger picture.

If you are receiving enough traffic for that to make a fundamental difference, you'll likely have enough potential or realized revenue to pay for a few more [Flask, Rails, "slow" framework] servers, or have enough developer time to warrant building it in Go.

The upside to using a "slow" framework is massive. Try writing an app like Ticketee[3] in Go, even with Gorilla et al and you'll realize the productivity gains you're missing out on.

For a small API, backend services, command line apps Go makes sense. But the big selling point there isn't speed, it's likely deployability.

I love Go. It's good for teams, deploys well, is enjoyable to program in, does things quickly. But if a client comes to me wanting a web application with forms, view logic, payments, 3rd party integrations – I'll take my Rails, thanks.

> Given all this, frameworks (and ecosystems) like Flask, Sinatra, Django and Rails still have an advantage for when you want to get something done today: they’re very useful toolboxes, handle a lot of the boilerplate and have a lot of examples and packages to leverage.

The author clearly recognizes this opinion – but there seems to be an idea that you can just "use Go" in place of existing web frameworks. That's not the case (yet!). I think this is largely driven by the myth of performance requirement.

[1]: Things like Node.js probably fit into this argument too

[2]: http://www.techempower.com/benchmarks/

[3]: https://github.com/steveklabnik/ticketee

[taude]

Nice arguments for "deployability" not something I initially would have thought to measure, since it's usually something that's "felt" later in the development/release process.

I guess it'll be interesting to watch how the frameworks mature and start to approach the Rails/Django or other micro-frameworks...

[elithrar]

> The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular Python framework at 18,945[2] (3.1 ms) is trivial when you look at the bigger picture.

I disagree, and think that's a huge difference. The latency may not be, but requests per second? That could be a significant amount of difference if you start pulling decent traffic: you need ten Flask servers for every one Go server. That's a lot of ops complexity you can save yourself right there.

Flask, mind you, has a much more mature ecosystem (WTForms, SQLAlchemy, et. al) and development is likely to be faster on that front, but if you're looking at building something scalable and don't mind a bit of groundwork now, there is an advantage to using Go. It just may not be an advantage for every team (and that's fine: horses for courses).

[pearkes]

> That's a lot of ops complexity you can save yourself right there.

If you're doing that kind of sustained request volume then you'd like have web server redundancy for availability reasons , right? Reverse proxying from nginx to a Go app vs. a flask/uwsgi app becomes a pretty small problem.

I'm definitely not arguing that Go isn't more "scalable". By all of our measures, it is. I'm talking about the huge sacrifices you make to productivity to use it as a developer for specifically modern web development.

[jaegerpicker]

I'd disagree that node.js fit that argument. I do python Django in my day job and a ton of node.js in my other projects (startup nearing launch, two other projects) and with express there is not a huge gulf in productivity between the two. All of my node.js projects is based upon No-SQL (leveldb, mongodb, couchdb) db's so I'm not up on JS's ORM libs but it might be a large difference there but it's certainly not when using a No-SQL db.

[pearkes]

Gotcha. Yea, I put that in there because I've read/heard second hand information about Node.js requiring a substantial amount of boilerplate, etc. Sounds like that time has past. :)