@dumpsterlid @ProdigalFrog Moondust would be heck on the bearings, though.

@Evinceo there's code generation, and there's optimization decisions. Optimization problems often have the property that their correctness is easily checked, but choosing the best one is hard. Register allocation is the easy-to-understand example -- if modeled as graph coloring, an incorrectly colored graph is trivial to detect.

So, sadly, not silly enough.

@Evinceo PCJ? And (lack of) reproducibility really would be a problem for Go, the LLM would need to expose all its random seeds and not have any run-to-run varying algorithms within it. This is not a joke or snark, the bits have to match on recompilation.

@corbin I'm curious how they deal with the Go builder (not compiler specifically) and all its signature verification hoo-hah. There's ways around that (and those are consistent with "trust nobody") but it's not usual case, and not tested nearly as hard as the default path. You can use your own builder, too, that's also an option (and now I wonder, could we get the Go builder to export a "build plan" for other-tool consumption?)

@corbin I got a 96GB laptop just so I could run (some) LLMs w/o network access, I'm sure that will be standard by 2025.🤪

@datarama @corbin The Go compiler requires reproducible builds based on a small set of well-defined inputs, if the LLM cannot give the same answer for the same question each time it is asked, then it is not compatible with use in the Go compiler. This includes optimizations -- the bits should be identical. #golang