4 ms·

Code generation is becoming really important in Go. Why even use an ORM when https://sqlc.dev/ https://sqlc.dev/ will generate everything from vanilla SQL? Wh

Code generation is becoming really important in Go. Why even use an ORM when https://sqlc.dev/ https://sqlc.dev/ will generate everything from vanilla SQL? Why make the frontend team write a Typescript client when https://goa.design https://goa.design on the backend will produce an OpenAPI schema they can just point a https://openapi-generator.tech https://openapi-generator.tech at? Why write out GraphQL boilerplate when https://github.com/99designs/gqlgen https://github.com/99designs/gqlgen will take your GQL typedef and generate it all for you based on how you want it to look. Why write validation rules when you can just define your input struct and let https://github.com/mustafaakin/gongular https://github.com/mustafaakin/gongular generate the rest for you? Honestly, I'm loving this. I want to focus on the entities and business logic - not writing yet another handler/resolver for basic auth + CRUD work.

yevpats 4y ago
100% ORMs becoming less and less relevant especially in Go with code generation and a bit of copilot help :). Also, Protobuf is another (not new) but good example of client and server side code generation which passed the time test.
zinclozenge 4y ago
Gongular looks pretty cool, but it seems like development stopped. Is there any other library that does similar things? I love learning about new frameworks/libraries in golang for exactly that reason of reducing boilerplate and spending more time on logic.
- stuzenz 4y ago
  Interesting response here in the issues. The project is still active. It seems that feature requests and issues are not being asked of the project. https://github.com/mustafaakin/gongular/issues/21 https://github.com/mustafaakin/gongular/issues/21
jerf 4y ago
It would be interesting for the annual Go survey to include a question about how much code generation is being used in the wild. My personal impression is that it is not widespread at all, but I phrase it that way on purpose.
- halpmeh 4y ago
  We've been using it for mocks and protocol buffers for many years. I'm sure we're not alone.
lairv 4y ago
sqlc is great but what I dislike about it is that it forces you into using only the supported underlying drivers, for example with postgresql the pgx v5 driver has been out for some times now but sqlc only support v4 (this might have changed recently I haven't checked). Overall there are many reasons why I would like to generate code slightly differently from what is done in the lib, I wish there was a way to have a highly customizable code generation experience
leetbulb 4y ago
Check out Ent https://entgo.io/docs/code-gen https://entgo.io/docs/code-gen Pretty easy to generate GraphQL (most fully featured extension), OpenAPI, Protobuf, etc. from your database schema. Ent also makes it easy to implement your own generators (e.g. OAS, glue logic, etc).
- Xeoncross 4y ago
  The problem with Ent is you are neither 1) writing your SQL structures or 2) writing your Go structures. Instead, you're writing Ent-specific structures. It's still a good option, just sad we keep inventing more abstraction layers that are unique in each language. That is a benefit of GraphQL typedefs, JSON, and SQL - it's the same in every language.
ilyt 4y ago
It's real shame it's kinda bad language for it. Looking at what people did with Rust macros it's shame that Go code generation story is either "just run some random binaries to compile stuff" or "put code instructing the compiler to do stuf in fucking comments" And I say it without being sarcastic but Go makes me miss C preprocessor and nothing should make anyone miss C preprocessor.
- rad_gruchalski 4y ago
  > put code instructing the compiler to do stuf in fucking comments Funny considering how Rust does stuff. Both approaches have pros and cons. One either digs through a shitload of macros, or commits explicit auto generated code.
  - ilyt 4y ago
    Yeah the annotations in Rust suffer from bit of that but macros don't. I yearn for ability to make error handling macros...
- teeray 4y ago
  It’s like metaprogramming in Ruby again, except with the idea that it’s somehow more straightforward because you can inspect the generated code. Except nobody will ever inspect auto-generated code because a) it’s usually awful code b) ignoring that code was kind of the whole point.
- philosopher1234 4y ago
  >Looking at what people did with Rust macros it's shame that Go code generation story is either "just run some random binaries to compile stuff" or "put code instructing the compiler to do stuf in fucking comments" Why is it a shame? Rely on macros and this is what you get: 1. Slow compile times 2. Unsearchable (grep, sourcegraph...) code 3. Magic codebases. Longer learning curve To me, working in a large organization, those are big downsides.
  - ilyt 4y ago
gmhafiz 4y ago
Sqlc quickly breaks down when you want to do dynamic select. This is where an orm, or query builder shines
- stereosteve 4y ago
  Agreed. I am experimenting with using go-jet instead and it’s going real good so far. https://github.com/go-jet/jet https://github.com/go-jet/jet
User23 4y ago
It's nice that they exist, but these workarounds are only necessary because Go isn't a very expressive language. I don't really consider having to use a third party tool to generate boilerplate as part of a multi-stage build process to really be a great thing, but I guess it's better than not having those tools if you choose to use Go for some reason.

yevpats 4y ago

100% ORMs becoming less and less relevant especially in Go with code generation and a bit of copilot help :). Also, Protobuf is another (not new) but good example of client and server side code generation which passed the time test.

zinclozenge 4y ago

Gongular looks pretty cool, but it seems like development stopped. Is there any other library that does similar things? I love learning about new frameworks/libraries in golang for exactly that reason of reducing boilerplate and spending more time on logic.

stuzenz 4y ago
Interesting response here in the issues. The project is still active. It seems that feature requests and issues are not being asked of the project. https://github.com/mustafaakin/gongular/issues/21 https://github.com/mustafaakin/gongular/issues/21

jerf 4y ago

It would be interesting for the annual Go survey to include a question about how much code generation is being used in the wild. My personal impression is that it is not widespread at all, but I phrase it that way on purpose.

halpmeh 4y ago
We've been using it for mocks and protocol buffers for many years. I'm sure we're not alone.

lairv 4y ago

sqlc is great but what I dislike about it is that it forces you into using only the supported underlying drivers, for example with postgresql the pgx v5 driver has been out for some times now but sqlc only support v4 (this might have changed recently I haven't checked). Overall there are many reasons why I would like to generate code slightly differently from what is done in the lib, I wish there was a way to have a highly customizable code generation experience

leetbulb 4y ago

Check out Ent https://entgo.io/docs/code-gen https://entgo.io/docs/code-gen Pretty easy to generate GraphQL (most fully featured extension), OpenAPI, Protobuf, etc. from your database schema. Ent also makes it easy to implement your own generators (e.g. OAS, glue logic, etc).

Xeoncross 4y ago
The problem with Ent is you are neither 1) writing your SQL structures or 2) writing your Go structures. Instead, you're writing Ent-specific structures. It's still a good option, just sad we keep inventing more abstraction layers that are unique in each language. That is a benefit of GraphQL typedefs, JSON, and SQL - it's the same in every language.

ilyt 4y ago

It's real shame it's kinda bad language for it. Looking at what people did with Rust macros it's shame that Go code generation story is either "just run some random binaries to compile stuff" or "put code instructing the compiler to do stuf in fucking comments" And I say it without being sarcastic but Go makes me miss C preprocessor and nothing should make anyone miss C preprocessor.

rad_gruchalski 4y ago
> put code instructing the compiler to do stuf in fucking comments Funny considering how Rust does stuff. Both approaches have pros and cons. One either digs through a shitload of macros, or commits explicit auto generated code.
- ilyt 4y ago
  Yeah the annotations in Rust suffer from bit of that but macros don't. I yearn for ability to make error handling macros...
teeray 4y ago
It’s like metaprogramming in Ruby again, except with the idea that it’s somehow more straightforward because you can inspect the generated code. Except nobody will ever inspect auto-generated code because a) it’s usually awful code b) ignoring that code was kind of the whole point.
philosopher1234 4y ago
>Looking at what people did with Rust macros it's shame that Go code generation story is either "just run some random binaries to compile stuff" or "put code instructing the compiler to do stuf in fucking comments" Why is it a shame? Rely on macros and this is what you get: 1. Slow compile times 2. Unsearchable (grep, sourcegraph...) code 3. Magic codebases. Longer learning curve To me, working in a large organization, those are big downsides.
- ilyt 4y ago

gmhafiz 4y ago

Sqlc quickly breaks down when you want to do dynamic select. This is where an orm, or query builder shines

stereosteve 4y ago
Agreed. I am experimenting with using go-jet instead and it’s going real good so far. https://github.com/go-jet/jet https://github.com/go-jet/jet

User23 4y ago

It's nice that they exist, but these workarounds are only necessary because Go isn't a very expressive language. I don't really consider having to use a third party tool to generate boilerplate as part of a multi-stage build process to really be a great thing, but I guess it's better than not having those tools if you choose to use Go for some reason.