[tptacek]

I'm a full-time Golang developer, the last product I shipped was a Rails app, and my career started in the 90s as a shrink-wrap C software developer. Golang is an unpleasant environment in which to build web applications:

* Good SQL persistence abstractions aren't there yet, so realistic SQL-backed applications depend on writing tons of raw SQL and (worse) parsing results. Like a savage.

* Golang's built-in templating is good for self-contained full templates but not great for hierarchies of templates and partials.

* Golang's net/http library is so good that it's a gravity well for other request handling abstractions, so that sessions, CSRF tokens, and access control either have to be built directly on Golang's equivalent of Rack, or inevitably get put into libraries that conceal too much of net/http.

"Going with the flow" and writing idiomatic Golang code feels a lot like writing those Sinatra apps where you get 1/3rd of the way through and regret not just using Rails.

You can totally write a good web app in Golang, especially if you're doing minimal serverside HTML generation and leaning on something like React or Angular or Ember instead. But it's not what Golang is best at.

Meanwhile, Scala is both a language designed in part for serverside web apps and built on the JVM.

If you're writing a web application, where your functionality is exposed by a port 443 that Firefox connects to directly and asks for "/" from, I'd prefer Scala to Golang.

Reasonable people can disagree or object to any of this, but I'm not going to waste time sugarcoating.

[4ydx]

Agreed: 1) SQL is not solved in an ORM sense. Yes you will have to write sql statements. I'm not so sure this is a bad thing.

Beg-to-differ: 1) Templating works very well for me. You can pass variables to embedded template "partials" within a template. You can define your own functions for the templating engine to use etc. 2) net/http + gorilla (or something similar) and you have all of net/http exposed with some sugar on top. 3) csrf tokens are just a simple library. Yes you do have to be sure to put them into your templates.

If you are having difficulty with a middle-ware concept in terms of golang there are plenty of resources online.

So I would say that I have a different feeling about making websites in golang :) I enjoy it.

[tptacek]

Those are a lot of the same things a Sinatra programmer could have said about using Sinatra instead of Rails. And it's true, you can, and in some cases you might even enjoy it (if nothing else, the code is more transparent in Sinatra or Golang).

If, however, you've had the experience of starting a project in Sinatra and ruefully finishing it in Rails, my advice is: don't do full-featured web apps entirely in Golang.

[mangeletti]

Thanks. This is really helpful advice, and the ORM-related comments you made resonate with me, because the use of abstracted data backing services is sort of the meat and potatoes in just about any web app I can think of, and this was a real pain point in my initial research of Go. All of the ORM-ish things I've found are mediocre, at best, IMHO.

I ROFL at "Like a savage.", btw.

[tptacek]

You can get around it by using more recent databases; Rethink for instance might close the gap. But then you're using an idiosyncratic database for kind of a weird reason. Personally, I want to preserve a default of using Postgres, and I don't like that Golang pulls me away from that a little.

That said: I really like Golang a lot.

For Microcorruption, we did the overwhelming majority in Golang, exposing it as a JSON RPC endpoint, and then did the UI in a very small amount of Rails. It worked quite well.

One thing you can for sure say about Golang: it is fast. We deployed 3 app servers but if we had deployed only 1 it still wouldn't have broken a sweat.

[mangeletti]

I agree 100% about your Postgres point. I don't want to ever be in a situation where I can't use Postgres, unless we're in a situation wherein Postgres has taken the back seat to some other database that is A) ACID compliant, B) really fast and scalable and B) fairly widely adopted.