4 ms·

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 th

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 12y ago
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 12y ago
  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.