I deleted the previous message, it was old and useless.
Thank you all for the support.
Il giorno giovedì 25 febbraio 2021 alle 22:42:03 UTC+1 TiT8 ha scritto:
> 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/810a6363-fff0-40df-abdb-28311c654d95n%40googlegroups.com.
