Re: [go-nuts] Contrary to popular opinion...

*There should be one-- and preferably only one --obvious way to do it. * >From the Zen of Python. But also good advice for Gophers. On Friday, 26 February 2021 at 01:03:00 UTC skinne...@gmail.com wrote: > I have a wonderful video of a GO program I wrote over 5 years ago which > will not compile

Re: [go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

What I mean is fmt.Println(v3) and fmt.Println(v3.Elem()) print the same thing. Is it an intended design? On Thursday, February 25, 2021 at 11:11:52 PM UTC-5 Kurtis Rader wrote: > On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com > wrote: > >> >> https://play.golang.org/p/-GZajVGPW

Re: [go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com wrote: > > https://play.golang.org/p/-GZajVGPWYv > You need to clarify your question. I don't see any obvious problem with the output of your program. The reflect.Value.Elem() call is defined to return a reflect.Elem object. But that observation

[go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

https://play.golang.org/p/-GZajVGPWYv -- 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

[go-nuts] Brook v20210214 Released – cross-platform strong encryption, undetectable proxy. Open Source via GPLv3

Brook is a cross-platform strong encryption and not detectable proxy. Brook's goal is to keep it simple, stupid and not detectable. Github: https://github.com/txthinking/brook Document: https://txthinking.github.io/brook/ -- You received this message because you are subscribed to the Google Gr

Re: [go-nuts] Error handling

> > I realize that this thread ended up diverging into a wider discussion of > exceptions and error handling in general but I wanted mention one of the > problems I discovered and maybe a potential solution for others who may be > tempted to play around with something like this. > > I originall

Re: [go-nuts] Contrary to popular opinion...

I have a wonderful video of a GO program I wrote over 5 years ago which will not compile today due to my failure to vendor one lost module. I too had multiple paths in my GOPATH and it varied upon the client. I consider the new modules an improvement but the adaptation has not been without pain.

Re: [go-nuts] Need help/tips on golang compiler souce code reading

Ian, I very much appreciate your taking the time to provide the history here. I am almost inclined to suggest that the OP create a design document much the way an engineer creates an as-built design before creating a new design. For my part, I would be willing to assist the OP on an occasional ba

[go-nuts] Re: Module dependency cycles

If I understand the post here, it seems we're also struggling with this issue with our private repos. For us it means that in the go.sum of the highest level repos there's references for everything, all the way back to the initial v0.0.0 versions of every package. AFAICT, this is happening wi

Re: [go-nuts] Contrary to popular opinion...

Given the writing on the wall that GOPATH is going away, what I have done is created a single module where I keep all my own code, each different experiment in its own subdirectory. I named it "github.com/...", but never submitted it to github, so in the future I can do that without too much fuss i

Re: [go-nuts] Contrary to popular opinion...

Agreed -- module mode is great for "delivered code". But in a personal single machine single developer environment, all the extra complexity and manual overhead might not worth it. I'd guess that most students and hobbyists don't even use SCMs. My point was that GOPATH mode is good for them. On Th

Re: [go-nuts] still struggling to understand modules

I solved my issue by restarting the terminal program.  The code now compiles.  And I also tested on Win10 and go 1.16. I'm glad I asked my question, because nothing I read said that all I had to do to use modules is to go into each code directory I use and    go mod init Perhaps that simpl

Re: [go-nuts] Re: Differences between go1.16 and go1.15 ?

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 convenie

Re: [go-nuts] Re: Differences between go1.16 and go1.15 ?

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 com

Re: [go-nuts] Contrary to popular opinion...

That is 100% true but a important point is that using GOPATH requires manual dependency management via ‘vendoring’. This can be very labor intensive and error prone - leading to security issues in your delivered code. > On Feb 25, 2021, at 3:08 PM, Bob Alexander wrote: > >  > GOPATH mode doe

Re: [go-nuts] Re: Differences between go1.16 and go1.15 ?

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 com

[go-nuts] Contrary to popular opinion...

GOPATH mode does *not *limit your Go code to a single directory. I've seen this misunderstanding stated in probably hundreds of various posts. $GOPATH allows specification of multiple directories. I've used that capability for several years to distribute my Go code to my personal general library

Re: [go-nuts] Re: Differences between go1.16 and go1.15 ?

On Wed, Feb 24, 2021 at 11:46 PM Volker Dobler wrote: > > On Wed, 24 Feb 2021 at 20:00, Ian Lance Taylor wrote: >> >> On Sat, Feb 20, 2021 at 8:26 AM Volker Dobler >> wrote: >> > >> > 1. Do not use go run main.go. Never! >> >> I want to point out that this is too strong. There are perfectly goo

Re: [go-nuts] Need help/tips on golang compiler souce code reading

On Wed, Feb 24, 2021 at 10:24 PM messi...@gmail.com wrote: > > I'm trying to read golang compiler source code and now have come to the > middle of syntax analysis: just finished parser.fileOrNil, next step is > noder.node(). > > So far everything is fine, both lex and syntax tree parsing is eas

Re: [go-nuts] Re: Cannot build after upgrading to Go 1.16

Because stdlib was written before modules were a thing. Regarding the "lets keep GOPATH going" argument, there was an issue about this on github where the arguments around the issue were fully explored. https://github.com/golang/go/issues/37755#issuecomment-771879911 > thanks. expressed virt

Re: [go-nuts] still struggling to understand modules

Thanks for answering me. Now I have a curious problem.  Most of the code I've written is compiling.  I'm using go 1.15.8 under ubuntu.  I did     I'm logged into ~/go/src     export GO111MODULE=on     cd multack    This is my code     go mod init multack     cd ..     Now I'm back

Re: [go-nuts] Differences between go1.16 and go1.15 ?

On 2/25/21 8:31 AM, Brian Candler wrote: > I suggest that newcomers are told to create an empty directory, create main.go > in that directory, and then use "go run ." (a literal dot), "go build .", "go > fmt ." etc.  Of course, this means that if you have several programs you need > to > create se

[go-nuts] Naming convention for a struct that writes other structs to an io.Writer?

Writer? Encoder? Putter? I am creating a library for writing certain data objects (hence MyStruct) to an io.Writer. I was trying to find how Go's standard library typically names interfaces like that so that I could stick to the conventional naming. Seems that the JSON

Re: [go-nuts] Differences between go1.16 and go1.15 ?

Hi Volker, > On 25. Feb, 2021, at 09:34, Volker Dobler wrote: > > Well, there is already subcommand "test": go test runs the (unit) tests > defined in the *_test.go files using package testing, so this won't work. > > Well there is nothing wrong with a plain "go run" (nor arguments at all) > or

Re: [go-nuts] Differences between go1.16 and go1.15 ?

On Thu, 25 Feb 2021 at 09:08, Paul Förster wrote: > Hi Volker, > > > On 25. Feb, 2021, at 08:46, Volker Dobler > wrote: > > > > 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_. > >

Re: [go-nuts] Differences between go1.16 and go1.15 ?

For me, it took a while to twig that the normal unit of compilation is the package, *and* that a package is normally a *directory* of files. "go run main.go" breaks this by having a special case where the package is a single file (or worse, a collection of listed files). I suggest that newcome

Re: [go-nuts] Differences between go1.16 and go1.15 ?

Hi Volker, > On 25. Feb, 2021, at 08:46, Volker Dobler wrote: > > 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_. I am a Go newbie and I agree, though I immediately understood that "g