[est31]

I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust.

The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup.

Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde, and monomorphized generics for basically everything). But all of this code is never checked into git (with the exception of some build.rs tools which can be configured to run as commands as well), or at least 99% of the time it's not.

This difference has impact on the developer story. In go land, you need to manually invoke the auto generator and it's easy to forget until CI reminds you. The auto generator is usually quite slow, and probably has much less caching smartness than the Rust people have figured out.

In Rust land, the auto generation can, worst case, run at every build, best case the many cache systems take care of it (cargo level, rustc level). But still, everyone who does a git pull has to re-run this, while with the auto generation one can theoretically only have the folks run it who actually made changes that changed the auto generated code, everyone else gets it via git pull.

So in Go, your IDE is ready to go immediately after git pull and doesn't have to compile a tree of hundreds of dependencies. Go IDEs and compilers are so fast, it's almost like cheating from Rust POV. Rust IDEs are not as fast at all even if everything is cached, and in the worst case you have to wait a long long time.

On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it). In Rust land, cargo creates some level of standardization.

You can always look at the auto generated Go code and understand it, while Rust's auto generated code usually is not IDE inspectable and needs special tools for access (except for the build.rs generated stuff which is usually put inside the target directory).

I wonder how a language that is designed from scratch would approach auto generation.

[mxey]

> On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it).

https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processin...

[Kinrany]

FYI rust-analyzer can show expanded macros. It's not perfect because you only get syntax highlighting, but it works.

[steveklabnik]

Yeah, this is a hard problem, and you're right that both have upsides and downsides. Metaprogramming isn't easy!

I know I don't want to have macros if I can avoid them, but I also don't forsee making code generation a-la-Go a first class thing. I'll figure it out.

[beautron]

> The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup.

Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation.

I'm sure there are projects out there with a "bunch" of it, but I don't think they are "typical".

[GeneralMayhem]

Same here. I've worked on one project that used code generation to implement a DSL, but that would have been the same in any implementation language, it was basically transpiring. And protobufs, of course, but again, that's true in all languages.

The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.

[tgv]

Me neither. My go code doesn't have any auto-generation. IMO it should be used sparingly, in cases where you need a practically different language for expressivity and correctness, such as a parser-generator.

[lenkite]

Anything and everything related to Kubernetes in Go uses code generation. It is overwhelmingly "typical" to the point of extreme eye-rolling when you need to issue "make generate" three dozen times a day for any medium sized PR that deals with k8s types.

[ryanobjc]

The "just generate go code automatically then check it in" is a massive miswart from the language, and makes perfect sense because that pathological pattern is central to how google3 works.

A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc.

So its an established Google standard, which has tons of help from their CI/CD systems.

For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience. Ditto monorepos. Ditto centralized package authorities for even private modules (my least fave feature of Go).

[mxey]

> For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience.

The golang/go repo itself has various checked-in generated repo

[auggierose]

Auto generation? If you need to use that a lot, then the programming language is defective, I would say.

[9rx]

When Go was launched, it was said it was built specifically for building network services. More often than not that means using protobuf, and as such protobuf generated code ends up being a significant part of your application. You'd have that problem in any language, theoretically, due to the design of protobuf's ecosystem.

Difference is that other languages are built for things other than network services, so protobuf is much less likely to be a necessary dependency for their codebases.