On Wed, 24 Feb 2021 at 20:00, Ian Lance Taylor <i...@golang.org> wrote:
> On Sat, Feb 20, 2021 at 8:26 AM Volker Dobler
> <dr.volker.dob...@gmail.com> wrote:
> >
> > 1. Do not use go run main.go. Never!
>
> I want to point out that this is too strong. There are perfectly good
> reasons to use "go run main.go". It's a simple convenience operation
> that does what it says. If you have a single file Go main package,
> "go run main.go" is fine. I do it all the time.
>
I admit that from a technical perspective of an expert
this advice is too strong. go run with filename arguments
exists for a purpose and of course I too do use go run gen.go
regularly and even go run main.go occasionally.
But unfortunately "go run main.go" seems to have become
a synonym for "run Go code", promoted and parroted on every
low barrier introduction blog post about Go resulting in a false
impression that "go run main.go" is "the way you execute Go code."
Which it is not in general, leading to a lot of confusion on questions
like:
- Why doesn't go run main.go work any longer if I move some of my code
to a new file server.go?
- Why doesn't go build main.go foo.go special.go not honour build tags?
- Why doesn't go test some_test.go run the tests in file some_test.go
but fails with compiler errors?
- Why does the trivial program package main; func main(){} lead to
memory allocations as can be seen by GODEBUG=gctrace=1 go run trivial.go
?
- Why shouldn't I execute my Go script in my docker container via go run?
- Why does importing import "./mypkg/mycode.go" throw an error but the
file ./mypkg/mycode.go does exist and contains the code?
[https://github.com/golang/go/issues/43970]
I think there is a major problem with "go run main.go": It creates
a _false mental model_ of how Go code is built and executed in the
minds of _beginners_. Experts know that Go code is not "executed"
but compiled, linked and the executable is loaded and executed.
Experts know that the Go's main building blocks are packages and
that the go tool works best on packages. Experts find it convenient to
run a file which is // +build ignore'ed. Experts find go run main.go
convenient and will switch to go build the moment it is no longer
a single main.go file without thinking about this switch.
But newcomers (especially coming from interpreted languages)
are not experts and I do believe that exposing them to
"go run main.go" does harm building a correct mental model
of how Go source code is compiled, linked and executed.
Why do people make the errors in the bullet list above?
Especially the last 4 points? My hypothesis is that they are too
much focused on _files_ than on packages. Why? Maybe because
if you are told "Use go run main.go to run your Go code." then
this settles the idea that source code files like main.go are the
relevant building blocks.
Because of that I think you "Never use go run main.go!" is a
good advice. It is an advice which is technically wrong.
But it helps building the right mental model of how Go works.
The advice/rule "You cannot divide by 0!" is a very good advice
albeit being technically wrong as there are rings with zero dividers
as we experts know. Nevertheless you always tell people to
_never_ divide by 0, a blunt lie. But you first have to understand
that "you cannot divide by 0" before you can do the expert step and
start working on abstract algebra and regularly use zero dividers.
In the same sense you have to understand first that the correct
way to build Go code is via "go build" (no arguments) which does
all the heavy lifting before you become an expert and will happily
and safely use go run with filename arguments.
V.
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAFdwN_%3DBKNOzh97LxSn7XVWCvVknDsNRjgmEq5%3D7Y8eS4H85gA%40mail.gmail.com.
