> I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure [..]
Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days.
> The "just use standard library" argument often seems a bit deceptive to me, though.
It is absolutely a mantra in the go community. No deception here.
> For example, how are you managing schema updates?
Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase.
But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.
Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days.
> The "just use standard library" argument often seems a bit deceptive to me, though.
It is absolutely a mantra in the go community. No deception here.
> For example, how are you managing schema updates?
Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase.
But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.