FrozenSake

One comment I'd make here is that that standard is much maligned and contentious. [This ](https://github.com/golang-standards/project-layout/issues/117) is not a fun read (unless you like popcorn drama), but I think shows...

Yeah, I think that's a good one. I'm not the main maintainer on my company's go monolith, but I was planning to ask him for some advice tomorrow morning as...

Okay, got advice from him, which was: > Rather than cookie-cutter project structure, I like thinking about "what goes in a package". Since the directory hierarachy means nothing in Go,...

I think the code makes sense for what it is now, yes. It follows pretty classic ruby on rails patterns, which I attribute to our use of an ORM.

Looks like the list of community files is: - CODE_OF_CONDUCT.md - CONTRIBUTING.md (done) - FUNDING.yml (Do we need it yet?) - issue templates (done) - pr templates - config.yml -...

Very belated: From a testing perspective, I think it's best to run your actual in-code tests with mocks, and then have a different test suite that tests your mocks against...

I agree with the questions. I think it's important that we clarify why we want an ORM and what we want it to do for us. It feels a bit...

I do think go is generally a pretty good language for not using an ORM (which I think correlates to how many ORMs are... not great?), but there seems to...

I think it's largely irrelevant if we do or don't in terms of go performance and usability, and I'd say the ORM pattern is one that people are comfortable with,...