Sorry for my late reply.

Thanks Ian for advice on the point "1" of Volker's list (and "fiuu", in 
that case go run is so convenient).

I tried benchmark the program (also with the formatting, with larger 
matrix) as exercise and everything work well (great performance, beautiful 
world that of compiled languages) both for go1.15.8 and go1.16. 

*So the answer to the title of this issue is NO *(Volker was right, 
obviously, I was wrong with nonsense comparison)*.*

Il giorno giovedì 25 febbraio 2021 alle 16:11:42 UTC+1 Ian Lance Taylor ha 
scritto:

> On Wed, Feb 24, 2021 at 11:46 PM Volker Dobler
> <dr.volke...@gmail.com> wrote:
> >
> > On Wed, 24 Feb 2021 at 20:00, Ian Lance Taylor <ia...@golang.org> wrote:
> >>
> >> On Sat, Feb 20, 2021 at 8:26 AM Volker Dobler
> >> <dr.volke...@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.
>
>
> That all makes sense, but in cases like this thread we are speaking
> with people new to Go and trying to be helpful. I understand better
> what you are saying when you say "Do not use go run main.go. Never!",
> but it's not a helpful way to begin a reply to a question that has
> nothing to do with "go run". The first response to a question should
> not be "You are doing it wrong!" when in fact this person was not
> doing it wrong. That isn't helpful.
>
> Perhaps you should write a blog post with something like the above
> information, and then you can link to it at the end of a reply, rather
> than as the first thing to say.
>
> Thanks.
>
> Ian
>

-- 
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/69c24ed2-512a-4754-b671-226531a6430cn%40googlegroups.com.

Reply via email to