I love Go, but there needs to be some work around dealing with the problems the community is solving via code generation.
I feel like a lot of the things I find tedious about Go should be much easier to generate somehow so I can get on with what I was trying to do. sqlboiler is an interesting version of something that Go by-it-self can't provide without code generation if you require not using reflection.
Otherwise, I like the language a lot. I mainly love it's simplicity to deploy, good cli, and low memory foot print. I also like that it's very easy to read, that the community is focused on "reading code", and that there are many good libraries out there now in addition to the standard library.
Started looking at Scala recently, and I'll probably play around with it, but it just seems Go is so much nicer to use for the kinds of projects I'm trying to develop.
I wish Go could have "just-in-time" code generation.
Right now, we have the magical //go:generate comment, but since it requires manual invocation of "go generate", artifacts can and do get out of sync with the Go code.
It would much nicer if Go code could contain code that caused generation to happen when the code was compiled. Adding the ability to execute Go at compile time would be one possible solution, similar to Rust's custom derive [1] support. As a use case, Rust has libraries that make extensive use of this system, such as serde [2], which can automatically generate efficient, type-safe serialization/deserialization code for structs (e.g. to/from JSON).
> Right now, we have the magical //go:generate comment, but since it requires manual invocation of "go generate", artifacts can and do get out of sync with the Go code.
It's pretty easy to enforce that as a build constraint in your CI system; we do that with our Go projects. If the output of `go generate` isn't checked into git, the build fails. (Same if the code hasn't been formatted with gofmt).
True, but you have to do it for every single project. We have tons of apps that all need to manage little rules like this, it gets pretty exhausting after a while.
And NOT having to maintain little rules like this is one of the reasons I fell in love with Go initially. Between gofmt and gofix, the go tooling just works(tm) so danm well.
Go seems to be a study in how to ignore decades of both acedemic research and practical experience. Did no one learn from Java that code generation is a red flag that something is wrong with your language?
I feel like a lot of the things I find tedious about Go should be much easier to generate somehow so I can get on with what I was trying to do. sqlboiler is an interesting version of something that Go by-it-self can't provide without code generation if you require not using reflection.
Otherwise, I like the language a lot. I mainly love it's simplicity to deploy, good cli, and low memory foot print. I also like that it's very easy to read, that the community is focused on "reading code", and that there are many good libraries out there now in addition to the standard library.
Started looking at Scala recently, and I'll probably play around with it, but it just seems Go is so much nicer to use for the kinds of projects I'm trying to develop.