3 ms·

> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should

> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. It's annoying to inspect and maintain and usually has quirks that I have to work around. How do Go developers feel about that?

mbrodersen 4y ago
The advantage of Codegen is that it works for any language. Whether the language has macros or whatever. Another advantage is that you can generate code for multiple languages (say Typescript and C#) from the same spec, making sure the client/server code stays 100% in sync. Codegen is my favourite super productivity tool. I routinely write production code where only the core biz logic is hand coded. The rest is fully automated. Most Excellent!
lordofgibbons 4y ago
I've never had an issue with code generation in Go. However, they do tend to be verbose - hopefully they will start using generics to re-use the common bits and cut down on the amount of generated code! The only instance I've had issues with them has been when generating code for things like schema languages (like GraphQL) on large projects where if you click to check the definition of a function/struct, the editor struggles a little to open up a file with tens of thousands of lines of code.
codeflo 4y ago
ORMs have the problem that the shape of the interface they provide mostly depends on configuration or data (the SQL schema). In static languages at least, this means that code has to be generated at some point. Tooling and convenience wise, there are differences between the approaches, but conceptually, does it really make a huge difference whether this step happens in a separate tool before compilation (seen here), or inside the compiler (in a macro system like Rust’s), or at runtime (as ORMs tend to do in JITted languages like Java and C#)?
- valenterry 4y ago
  > ORMs have the problem that the shape of the interface they provide mostly depends on configuration or data (the SQL schema). In static languages at least, this means that code has to be generated at some point. Maybe for most languages that's true, but in general I don't think it is. > Tooling and convenience wise, there are differences between the approaches, but conceptually, does it really make a huge difference whether this step happens in a separate tool before compilation (seen here), or inside the compiler (in a macro system like Rust’s), or at runtime (as ORMs tend to do in JITted languages like Java and C#)? Between runtime and compiletime or code generation there is certainly a big difference. Between compile-time (or macro time) and code generation I think too. The reason is that, for instance, if it happens at compile-time then you have types that you can work with. You can use those types and reshape them to create even more types. E.g. you could take the database schema types and generate graphql types. That means, the mapping from the database to the types of the programming language has to be done only once and then other libraries can build upon it without containing this part anymore. But if you use code generation, essentially every library has to know how to get the types from the database, since it is very hard to take the generated code and then transform it into types or code for e.g. graphql. Unless you parse the generated code and then transform it. Not only is there now a problem of the order of code generation but I believe it is also inherently harder to parse arbitrary code compared to parsing arbitrary types, simply due to the fact that types are much more restricted in what they can express.
impulser_ 4y ago
Code generation is feature of Go. We use it with ent to generate clients, services, and database all together using the same ent scheme. We even use it to generate clients and servers for other languages with the help of templates. The language is small and simple that maintaining the generated code isn't that big of a problem as you might think.
miffy900 4y ago
> Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. A good use of code generation is to relieve yourself the burden of hand-writing repetitive mapping code, especially when modelling the database structure in application code. This is a perfect use case for that. Same is true for generating a client to some external API. Otherwise I'm inclined to agree with you. A few times, I've written code generators before and realised I could've gotten away with some generic programming. But that has its own set of gotchas and caveats. Though go has support for some generic programming now.
kbumsik 4y ago
I started to like Go's code generation approach. Code generation make you very productive since IDE's auto-complete and code search works perfectly and snappy with the generated code. The only complaint is that it tends to make noise during code reviews because they include autogenerated code too.
- vbezhenar 4y ago
  Is it considered OK to commit autogenerated code? With Java I don't do that. It's generated during build phase in output folders but never commited to the VCS. Never had any issues with that.
  - kbumsik 4y ago
    There is nothing wrong with committing generated code in Ent and Go. I don't know about Java but in Golang it does not create any platform-specific code in general, so committing code in the VCS would ensure reproducibility. It is still OK to commit without generated code and things won't break as long as you pinned the package versions correctly. But some people don't like to put extra burden in the build phase. So it is totally organization's decision whether to commit generated code or not.

mbrodersen 4y ago

The advantage of Codegen is that it works for any language. Whether the language has macros or whatever. Another advantage is that you can generate code for multiple languages (say Typescript and C#) from the same spec, making sure the client/server code stays 100% in sync. Codegen is my favourite super productivity tool. I routinely write production code where only the core biz logic is hand coded. The rest is fully automated. Most Excellent!

lordofgibbons 4y ago

I've never had an issue with code generation in Go. However, they do tend to be verbose - hopefully they will start using generics to re-use the common bits and cut down on the amount of generated code! The only instance I've had issues with them has been when generating code for things like schema languages (like GraphQL) on large projects where if you click to check the definition of a function/struct, the editor struggles a little to open up a file with tens of thousands of lines of code.

codeflo 4y ago

ORMs have the problem that the shape of the interface they provide mostly depends on configuration or data (the SQL schema). In static languages at least, this means that code has to be generated at some point. Tooling and convenience wise, there are differences between the approaches, but conceptually, does it really make a huge difference whether this step happens in a separate tool before compilation (seen here), or inside the compiler (in a macro system like Rust’s), or at runtime (as ORMs tend to do in JITted languages like Java and C#)?

valenterry 4y ago
> ORMs have the problem that the shape of the interface they provide mostly depends on configuration or data (the SQL schema). In static languages at least, this means that code has to be generated at some point. Maybe for most languages that's true, but in general I don't think it is. > Tooling and convenience wise, there are differences between the approaches, but conceptually, does it really make a huge difference whether this step happens in a separate tool before compilation (seen here), or inside the compiler (in a macro system like Rust’s), or at runtime (as ORMs tend to do in JITted languages like Java and C#)? Between runtime and compiletime or code generation there is certainly a big difference. Between compile-time (or macro time) and code generation I think too. The reason is that, for instance, if it happens at compile-time then you have types that you can work with. You can use those types and reshape them to create even more types. E.g. you could take the database schema types and generate graphql types. That means, the mapping from the database to the types of the programming language has to be done only once and then other libraries can build upon it without containing this part anymore. But if you use code generation, essentially every library has to know how to get the types from the database, since it is very hard to take the generated code and then transform it into types or code for e.g. graphql. Unless you parse the generated code and then transform it. Not only is there now a problem of the order of code generation but I believe it is also inherently harder to parse arbitrary code compared to parsing arbitrary types, simply due to the fact that types are much more restricted in what they can express.

impulser_ 4y ago

Code generation is feature of Go. We use it with ent to generate clients, services, and database all together using the same ent scheme. We even use it to generate clients and servers for other languages with the help of templates. The language is small and simple that maintaining the generated code isn't that big of a problem as you might think.

miffy900 4y ago

> Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. A good use of code generation is to relieve yourself the burden of hand-writing repetitive mapping code, especially when modelling the database structure in application code. This is a perfect use case for that. Same is true for generating a client to some external API. Otherwise I'm inclined to agree with you. A few times, I've written code generators before and realised I could've gotten away with some generic programming. But that has its own set of gotchas and caveats. Though go has support for some generic programming now.

kbumsik 4y ago

I started to like Go's code generation approach. Code generation make you very productive since IDE's auto-complete and code search works perfectly and snappy with the generated code. The only complaint is that it tends to make noise during code reviews because they include autogenerated code too.

vbezhenar 4y ago
Is it considered OK to commit autogenerated code? With Java I don't do that. It's generated during build phase in output folders but never commited to the VCS. Never had any issues with that.
- kbumsik 4y ago
  There is nothing wrong with committing generated code in Ent and Go. I don't know about Java but in Golang it does not create any platform-specific code in general, so committing code in the VCS would ensure reproducibility. It is still OK to commit without generated code and things won't break as long as you pinned the package versions correctly. But some people don't like to put extra burden in the build phase. So it is totally organization's decision whether to commit generated code or not.