gorp

> What's your preferred approach to store table definitions and migrations? Schema versioning and ORM can be quite orthogonal, unless your ORM decides to be as opinionated about stuff as e.g. ActiveRecord. In Go, I use migrate [1] and Gorp [2]. Granted, I have to tell the column names to Gorp manually, but that is a minor annoyance which I'm happy to pay for clean separation of concerns. > Doesn't [using SQL for table definitions and migrations] make them more susceptible to mistakes? What mistakes do you have in mind? Typos etc. will be caught by tests that access the database. That leaves actual design errors, which can happen just as easily in ORM code as in SQL code. [1] https://github.com/mattes/migrate [2] https://github.com/go-gorp/gorp

Go optimizes for readability and lack of surprise at the expense of conciseness, which is why you feel it may not be productive. I think that the better maintainability vs. something like Rails massively outweighs the upfront cost of having to type more code, but other people might judge differently. Furthermore, Go emphasizes "doing it your own way". There are no big web frameworks in Go, you just pull in some small and rather orthogonal libraries and make up your own abstractions to tie them together as you build your application. The end result is something that's highly optimized for your personal needs, but it requires a certain way of thinking and working that's not for everyone (and not always desirable). Some people do better when given more freedom; those should prefer Go etc. Some people do better when working within a well-know