[go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows
Hi Declan, Virus scanners can slow things down significantly on Windows, including virus scanners can go into overdrive if you are touching many files, touching files with atypical extensions, or building and then immediately executing a new binary. To start, you could try temporarily disabling your virus scanner and see if it helps. If it does help, you might be able to benefit from finer grain changes. Most virus scanners support exclusion lists if you have sufficient privileges. You could try for example excluding (1) the directories with your Go code, (2) the directory shown in 'go env GOCACHE', (3) possibly the directory shown in 'go env GOMODCACHE', and possibly others. I would be curious to hear your results. Even if this is not the particular problem you hit, it is something other gophers hit, and it would be nice to document this somewhere if it isn't already. Separately, I thought that Rust for example would add some default exclusions for Windows Defender, which could be an option for the Go Windows installer. However, I'm not seeing that just now based on some quick spot checking, so maybe that's something Rust only used to do, or perhaps I am thinking of something else. Finally, especially if you are in a corporate environment, there can be other security agents, network services, proxies, and other agents that can interfere with development performance beyond virus scanners. Regards, thepudds On Wednesday, December 14, 2022 at 12:57:40 PM UTC-5 Declan Finn wrote: > Hi, > > Platform: Windows 10 > Go Version: 1.19.4 > > Compile and run of the most basic helloworld program is extremely slow on > my windows machine, taking roughly 30 seconds every time. > Whereas the exact same program, using the same go version, compiles and > runs in under 1 second on my Ubuntu machine. > Why is it so slow on windows? > I asked a collogue to do the same test on his windows machine and he sees > the same slowness. > Any help would be greatly appreciated. > > > -- 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/3f6631a6-5b0f-401c-bc38-e00225f5a4a2n%40googlegroups.com.
Re: [go-nuts] where is GOROOT set?
Hi Pat, FWIW, I pulled together a TLDR on modules some time ago that I think hits upon each of the different issues you encountered in this thread. It also tries to summarize the core modules concepts, along with a bit of advice on how to stay on the "happy path" when starting out with Go modules. It is located here: https://stackoverflow.com/a/57314494/11210494 That might be worth a quick read, especially if you found anything puzzling so far. It is likely also worthwhile to go through the official Go modules tutorial from the Go project: https://go.dev/doc/tutorial/create-module Finally, looking over the thread, it seems you started by chasing how to set GOROOT, which makes sense given the main error message you first saw mentions GOROOT. GOROOT was a bit of a red herring, and I opened an issue suggesting that error message be modified to something more helpful: #56965 -- cmd/go: consider reducing use of the word 'GOROOT' in error messages https://github.com/golang/go/issues/56965 Feel free to comment there or here if you have any additional thoughts on what would have made your journey simpler. Best regards, thepudds On Friday, November 25, 2022 at 10:48:40 PM UTC-5 pat2...@gmail.com wrote: > Thanks > That seems to be the solution > -- 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/c3c5c0ea-4d01-4bbb-9aa8-4442abfd459bn%40googlegroups.com.
[go-nuts] Re: How go.work knows which module refers to which folder
Hi there, I might be misunderstanding your question, but a 'use' directive in a go.work file points to a directory. In your example, there would not be any ambiguity -- 'use ./hello' in a go.work file would refer to whatever module you have located in the 'hello' directory in your local filesystem immediately below the go.work file. >From the Go workspaces reference (https://go.dev/ref/mod#workspaces) : > A 'use' adds a module on disk to the set of main modules in a workspace. Its argument is a relative path to the directory containing the module’s go.mod file. A 'use' directive does not add modules contained in subdirectories of its argument directory. Those modules may be added by the directory containing their go.mod file in separate 'use' directives. Hope that helps, and sorry if that does not address your question. Regards, thepudds On Wednesday, April 6, 2022 at 9:43:12 AM UTC-4 Jack Li wrote: > Hi group, > > In the go.mod replace way, there’s a one-to-one mapping relationship, for > example, the module example.com/hello is mapped to folder …/hello > > ``` > $ go mod edit -replace example.com/hello=../hello > $ view go.mod > replace example.com/hello => ../hello > $ > ``` > > Now with the go.work way. If I've got three repos or modules like this: > > ``` > module main > go 1.18 > require example1.com/hello v1.0.0 > require example2.com/hello v1.0.0 > require example3.com/hello v1.0.0 > ``` > > How can go.work know which module above, refers to ./hello ? > > ``` > go.work: > use ./hello > ``` > > Thanks > -- 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/7c90c2a4-7a81-4e16-b1fe-8ddd19b72f12n%40googlegroups.com.
[go-nuts] [generics] type switches
Hello fellow gophers,
Ian announced the intention to update how type switches work in the
generics proposal in a golang-nuts thread from this August:
https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw
It included this from Ian (which is a snippet of his item #4 from his first
post there):
--
In a type switch on a type parameter with a type list, every case
listed must be a type that appears in the type list (“default” is also
permitted, of course). A case will be chosen if it is the type matched
by the type argument, although as discussed above it may not be the
exact
type argument: it may be the underlying type of the type argument. To
make
that rule very clear, type switches will not be permitted for type
parameters that do not have type lists.
--
There was a follow-on discussion in that thread on the desired type switch
behavior, including gophers like Rog Peppe and Jimmy Frasche commenting on
what they were hoping this meant.
I think the conclusion of that conversation might have been that adjustment
in type switch behavior suggested by Ian was not adopted as part of the
current proposal... but I'm not 100% sure, and wanted to check if that is
indeed the case (vs. maybe it was adopted, and perhaps I am just missing
how it works in the current go2go prototype, or maybe it is still planned
to be adopted but maybe the proposal and/or prototype haven't been updated
yet).
The most definitive comment from Ian as part of that conversation might
have been:
--
https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw/m/5KceLsiLBAAJ
--
Given a type parameter, there are two interesting pieces of
information. One is what the actual type argument is; we can already
determine that by writing code like "var x T; switch
(interface{})(x).(type) { ... }". The other is which type in the type
list was matched by the type argument. The latter is the purpose of
the type switch suggested here. Without something like that type
switch, there is no straightforward way for a generic function to
determine which type in a type list is matched by a type argument.
See also
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type
I'm not at all wedded to this. We can continue to omit it. It just
seems like adding a capability that does not otherwise exist.
--
The current draft seems to hold out the following as a future option:
--
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type
--
One way to handle this would be to permit type switches on the type T,
with the
proviso that the type T would always match a type defined in the
constraint. This
kind of type switch would only be permitted if the constraint lists
explicit types,
and only types listed in the constraint would be permitted as cases.
--
In any event, I am curious about the latest thinking and/or latest status.
If this has been discussed at length elsewhere since that August thread, I
would be happy for a pointer if anyone has one.
Thanks, and sorry if the answer is I am just confused ;-)
Best regards,
thepudds
--
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/dbdc0e64-b41d-4c69-9218-5972dc3b21a3n%40googlegroups.com.
