I figured Claude was an interested party, so I asked it to read this thread
and comment.
Here's what it came back with:
*This proposal won't happen, and for good reasons:*
1. *The problem is backwards* - LLMs hallucinating non-existent Go flags
is a training data issue, not a Go toolchain issue. Fixing Go to match LLM
hallucinations
sets a terrible precedent.
2. *The cost/benefit is poor* - Adding inline code execution to go run is
non-trivial (argument parsing, stdin handling, module context, error
reporting) for marginal
benefit. The pipe workaround works fine: echo 'package main; func main()
{ println("hi") }' | go run .
3. *Flag conflict* - go test -c already means "compile but don't run."
Overloading -c to mean "inline code" in go run violates consistency.
4. *Wrong tool for the job* - If you want a Go REPL or quick evaluation,
use dedicated tools like gomacro, gore, or yaegi. The go command is a build
tool, not an
interpreter.
5. *The Pike objection* - The reference to "Mr. Pike's objection" likely
refers to Rob Pike's general philosophy against adding complexity for
convenience when
simpler alternatives exist.
*The real fix*: Update LLM training to stop hallucinating go run -c. This
is a model correction issue, not a language tooling gap.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAGrodq-GPD2VrRAgMWOMz6NV7j6q9SHUj4AnA__N%3DJSt3gQ4fw%40mail.gmail.com.
