[go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows
It can also be something to exclude the tmp directory in which Go compiles when you do a 'go run' (I assume you meant that when saying 'build and run') What happens if you just build? - Is this slow what happens if you just execute? - Is this slow? What happens if you go install some-tool and run that? - is that slow? Op woensdag 14 december 2022 om 21:03:26 UTC+1 schreef thepud...@gmail.com: > 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/13d8ed63-2d9a-4852-9ac7-ce0c0215a553n%40googlegroups.com.
Re: [go-nuts] Linting
> But perhaps I'm just a sucker for quality and maintainability and I'm
barking up the wrong tree.
I don't think that you will find many people here who don't think that code
quality and maintainability
are important.
But I would disagree with the implicit assumptions that
code that "passes" a linter is of high quality
and that code that "fails" the linter is of poor quality
>From my limited readings of the Go source code, I would say that the Go
team's judgement of code quality is far beyond that
of any linter I have seen.
On Wednesday, 14 December 2022 at 23:07:24 UTC marc...@gmail.com wrote:
>
>
> Sorry, but I didn't state (and so does the linter) that any code is
> deficient.
> Normal usage of a linter is not to satisfy a linter, but to do some basic
> code review.
> (Most new linters can skip certain code lines these days too.)
>
> I know that the number of lines in a single function is just a matter of
> taste.
> But I also know that a function with too many lines is also harder to
> maintain.
> If you study those functions that are "too long", you will find that it
> could probably be split up in a more readable and maintainable way.
>
> The only worry I have is that complex code is very hard to maintain,
> perhaps only by a single person.
> What happens if that person isn't available anymore? The best time to
> maintain code to a more maintainable version, is at the moment of creation
> or not much later,
> because only then it lives still "in the mind" of the creator. A linter
> can help detect those "blindspots" of a developer and can point out where
> those are.
>
> With the new guidelines, one can expect to see the Go code as an example
> of those guidelines.
> (one of them being maintainable software)
>
> Does anybody have to fix all of it now? Of course not, but perhaps when a
> developer is touching one of those functions and understands what it does,
> then it is still the ideal time to rewrite it a bit.
>
> But perhaps I'm just a sucker for quality and maintainability and I'm
> barking up the wrong tree.
> I very much want Go to survive, so for me that means that people should
> not be afraid to maintain parts of the code.
> (and that's why I said not to touch all those high complexity parts,
> because I find it highly confusing; so i'm not fit for that job.)
>
> Op wo 14 dec. 2022 om 23:33 schreef Amnon :
>
>> This long discussion started with the question why the Go source is not
>> linted.
>> But I think the OP has answered his own question by providing us with a
>> list of 963 places
>> where the linter has decided that the code is deficient.
>> But what is notable, is that he has not given a single example where any
>> of these 963 warning has any value.
>> He has not taken even one of these warnings and show how "fixing" it
>> leads to better code.
>> 411 of these warnings are for functions which are longer than the 150
>> lines which are "allowed".
>> So I would ask: "allowed by whom?"
>> I am a big fan of short functions, as are the authors of the Go standard
>> library. But surely the optimal length of a function depends
>> on the context. I am not too bothered, about the length of functions in
>> the output of code generation, for instance. And I am OK with
>> code with a very regular structure - like a switch statement handling
>> many cases to take many lines.
>> Some of these linters do seem to be quite bureaucratic - imposing
>> arbitrary rules irrespective of whether they make sense in the actual
>> context.
>> Code written in corporations (because it usually is in corporations)
>> where these linters are imposed, have a particular smell, with all kinds
>> of convolutions and ugliness designed to appease the linter.
>> If you see code where every line begins with
>>
>> _, _ =
>>
>> Or where you always see
>>
>> defer func() { _ = res.Body.Close())()
>>
>> rather that
>>
>>defer res.Body.Close()
>>
>> you know that this is the product of a programmer toiling under the
>> dictates of a linter.
>> Because if you are discussing some code with a knowledgeable reviewer,
>> you can defend your decisions.
>> You can explain why writing to a byte.Buffer can not fail (unless we are
>> out of memory, in which case any error
>> handling will fail too). But if you are told off by a linter, there is no
>> appeal. The linter has no discretion.
>> It is not open to discussion. It will not consider your arguments. Your
>> job is to do what the linter tells you.
>> Because the linter is always right. Because the computer is always right.
>> And you, as a mere human, are always wrong.
>>
>> I would say that go vet is an exception - its warnings almost always
>> point to real problems in the correctness of code,
>> or unnecessary complexity. I often also run staticcheck on my own code.
>> It often makes useful observations, some of which
>> lead to useful changes. But beyond these two, linters often do more harm
>> than
[go-nuts] Re: Achieving C/C++/Rust comparable performance with Golang
two comments a) use many cores. Suddenly your Go code runs circles around everything else-- i.e. those languages you mention where doing multicore in a pain. The view that other languages are faster comes from an age long ago of single core machines. b) rather than pre-mature optimization, the general wisdom, and my specific heartfelt advice, is to measure where the time and memory is actually being spent, and then optimize from there. Generally this will 100x speed your development time, and you may find it is plenty fast already, this is on top of the 10x - 20x development speed over C++ that you already get with Go. Should tuning be desired subsequently, when it comes to profiling, the Go tools are so vastly superior to anything else out there, that you can easily find the hot spots and focus your optimization with laser precision. This is much more productive than trying to guess in general and over generalized terms about how a given application could perform under different languages. On Wednesday, December 14, 2022 at 11:57:40 AM UTC-6 Kursk wrote: > Hi, > Go is a high performant garbage collected language, (considered) memory > safe programming language, and as such its performance may not be > comparable with other languages such as C/C++/Rust under certain > application scenarios. > > I was wondering, how much of the Go language could be stretched (or > ignored) to produce as close as possible performance results if for > example, we write a program whose garbage collector have no work to do, > assuming that we can pre-allocate all required heap space, or that we could > somehow work around memory safety control points such as, index boundary > checking, etc. > > - Which one those performance penalty points would exactly be? > - Which ones would be impossible to workaround? > - What instructions/operations would be generally speaking comparable? > > I know this is a very abstract and theoretical question, I am of course > not expecting a conclusive/concrete answer to my questions but just some > general answer, to increase my understanding about language performance > while providing some pointers to continue my research on the topic. > > This will hopefully lead me to a better general understanding on where to > seek for potential optimisation opportunities within the Go language itself > vs scenarios where a port to C/C++/Rust would most likely be a better > option. > > Thanks in advance. > -- 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/e4cc9ccf-115e-4f88-8ecb-cf1b0d35537bn%40googlegroups.com.
Fwd: [go-nuts] Linting
Sorry, but I didn't state (and so does the linter) that any code is
deficient.
Normal usage of a linter is not to satisfy a linter, but to do some basic
code review.
(Most new linters can skip certain code lines these days too.)
I know that the number of lines in a single function is just a matter of
taste.
But I also know that a function with too many lines is also harder to
maintain.
If you study those functions that are "too long", you will find that it
could probably be split up in a more readable and maintainable way.
The only worry I have is that complex code is very hard to maintain,
perhaps only by a single person.
What happens if that person isn't available anymore? The best time to
maintain code to a more maintainable version, is at the moment of creation
or not much later,
because only then it lives still "in the mind" of the creator. A linter can
help detect those "blindspots" of a developer and can point out where those
are.
With the new guidelines, one can expect to see the Go code as an example of
those guidelines.
(one of them being maintainable software)
Does anybody have to fix all of it now? Of course not, but perhaps when a
developer is touching one of those functions and understands what it does,
then it is still the ideal time to rewrite it a bit.
But perhaps I'm just a sucker for quality and maintainability and I'm
barking up the wrong tree.
I very much want Go to survive, so for me that means that people should not
be afraid to maintain parts of the code.
(and that's why I said not to touch all those high complexity parts,
because I find it highly confusing; so i'm not fit for that job.)
Op wo 14 dec. 2022 om 23:33 schreef Amnon :
> This long discussion started with the question why the Go source is not
> linted.
> But I think the OP has answered his own question by providing us with a
> list of 963 places
> where the linter has decided that the code is deficient.
> But what is notable, is that he has not given a single example where any
> of these 963 warning has any value.
> He has not taken even one of these warnings and show how "fixing" it leads
> to better code.
> 411 of these warnings are for functions which are longer than the 150
> lines which are "allowed".
> So I would ask: "allowed by whom?"
> I am a big fan of short functions, as are the authors of the Go standard
> library. But surely the optimal length of a function depends
> on the context. I am not too bothered, about the length of functions in
> the output of code generation, for instance. And I am OK with
> code with a very regular structure - like a switch statement handling many
> cases to take many lines.
> Some of these linters do seem to be quite bureaucratic - imposing
> arbitrary rules irrespective of whether they make sense in the actual
> context.
> Code written in corporations (because it usually is in corporations) where
> these linters are imposed, have a particular smell, with all kinds
> of convolutions and ugliness designed to appease the linter.
> If you see code where every line begins with
>
> _, _ =
>
> Or where you always see
>
> defer func() { _ = res.Body.Close())()
>
> rather that
>
>defer res.Body.Close()
>
> you know that this is the product of a programmer toiling under the
> dictates of a linter.
> Because if you are discussing some code with a knowledgeable reviewer, you
> can defend your decisions.
> You can explain why writing to a byte.Buffer can not fail (unless we are
> out of memory, in which case any error
> handling will fail too). But if you are told off by a linter, there is no
> appeal. The linter has no discretion.
> It is not open to discussion. It will not consider your arguments. Your
> job is to do what the linter tells you.
> Because the linter is always right. Because the computer is always right.
> And you, as a mere human, are always wrong.
>
> I would say that go vet is an exception - its warnings almost always point
> to real problems in the correctness of code,
> or unnecessary complexity. I often also run staticcheck on my own code. It
> often makes useful observations, some of which
> lead to useful changes. But beyond these two, linters often do more harm
> than good. One very high quality linter with
> few false positives is far more valuable that a large number of linters
> which make nonsensical complaints.
> golangci_lint is particularly bad in this respect - making it easy to run
> loads of low quality linters, which cry wolf all the time and
> train programmers to ignore warnings.
>
> So I would appeal Ian and the rest of the Go team, to resist the pressure
> to adopt these "great linters" - not to invest months of work
> "fixing" these 963 "problems" identified by these linters. And focus on
> carrying on doing what you are doing - producing,
> rocks solid releases, well thought out enhancements, and code which can
> serve as a template we can all emulate
> to produce good, clear, idiomatic code.
>
>
> On Tuesday, 13 December 2022
Re: [go-nuts] Linting
This long discussion started with the question why the Go source is not
linted.
But I think the OP has answered his own question by providing us with a
list of 963 places
where the linter has decided that the code is deficient.
But what is notable, is that he has not given a single example where any of
these 963 warning has any value.
He has not taken even one of these warnings and show how "fixing" it leads
to better code.
411 of these warnings are for functions which are longer than the 150 lines
which are "allowed".
So I would ask: "allowed by whom?"
I am a big fan of short functions, as are the authors of the Go standard
library. But surely the optimal length of a function depends
on the context. I am not too bothered, about the length of functions in the
output of code generation, for instance. And I am OK with
code with a very regular structure - like a switch statement handling many
cases to take many lines.
Some of these linters do seem to be quite bureaucratic - imposing arbitrary
rules irrespective of whether they make sense in the actual context.
Code written in corporations (because it usually is in corporations) where
these linters are imposed, have a particular smell, with all kinds
of convolutions and ugliness designed to appease the linter.
If you see code where every line begins with
_, _ =
Or where you always see
defer func() { _ = res.Body.Close())()
rather that
defer res.Body.Close()
you know that this is the product of a programmer toiling under the
dictates of a linter.
Because if you are discussing some code with a knowledgeable reviewer, you
can defend your decisions.
You can explain why writing to a byte.Buffer can not fail (unless we are
out of memory, in which case any error
handling will fail too). But if you are told off by a linter, there is no
appeal. The linter has no discretion.
It is not open to discussion. It will not consider your arguments. Your job
is to do what the linter tells you.
Because the linter is always right. Because the computer is always right.
And you, as a mere human, are always wrong.
I would say that go vet is an exception - its warnings almost always point
to real problems in the correctness of code,
or unnecessary complexity. I often also run staticcheck on my own code. It
often makes useful observations, some of which
lead to useful changes. But beyond these two, linters often do more harm
than good. One very high quality linter with
few false positives is far more valuable that a large number of linters
which make nonsensical complaints.
golangci_lint is particularly bad in this respect - making it easy to run
loads of low quality linters, which cry wolf all the time and
train programmers to ignore warnings.
So I would appeal Ian and the rest of the Go team, to resist the pressure
to adopt these "great linters" - not to invest months of work
"fixing" these 963 "problems" identified by these linters. And focus on
carrying on doing what you are doing - producing,
rocks solid releases, well thought out enhancements, and code which can
serve as a template we can all emulate
to produce good, clear, idiomatic code.
On Tuesday, 13 December 2022 at 22:18:14 UTC marc...@gmail.com wrote:
> I have no complaints, let me be clear about that. Just advice, for all
> I've learned in my cariere is that maintenance is happening more than the
> first version of something creative.
> But I've still got hope that one day I might understand some complex
> coding that I didn't write myself.
>
> I'm happy to help, if an author of something "complex" can guide me. The
> only thing I can do now, is be a messenger.
>
>
> Op di 13 dec. 2022 om 20:52 schreef Ian Lance Taylor :
>
>> On Tue, Dec 13, 2022 at 2:31 AM Brian Candler wrote:
>> >
>> > With that in mind, I'd respectfully suggest that your starting point
>> should be to pick one of these "over complex" functions, understand it
>> fully, and rewrite it in what you consider to be a simpler/clearer way
>> which does not break any functionality, *and* which does perform any worse
>> than the original code (*). Then you can submit it as a pull request for
>> review. Rinse and repeat.
>>
>> With respect, I'm going to suggest not doing that. If code is working
>> correctly, then changing it, even to simplify it, may cause it to stop
>> working correctly. In fact, this is more likely to happen if the
>> original code is complex. The best approach to complex working code
>> is to only change it if there is a good reason to do so: because the
>> requirements have changed, or because there is some way to make it run
>> measurably faster, or because it is a regular source of bugs.
>>
>> Also I hope we can all agree that blind adherence to any specific
>> definition of complexity is misguided. For example, a function that
>> is basically a big switch statement with a bunch of cases is often
>> easier to understand as a single function rather than a
Re: [go-nuts] Achieving C/C++/Rust comparable performance with Golang
Same holds true for Java. People have tried What you end up with is Java is name only - so why bother. > On Dec 14, 2022, at 2:47 PM, Ian Lance Taylor wrote: > > On Wed, Dec 14, 2022 at 9:57 AM Kursk wrote: >> >> Go is a high performant garbage collected language, (considered) memory safe >> programming language, and as such its performance may not be comparable with >> other languages such as C/C++/Rust under certain application scenarios. >> >> I was wondering, how much of the Go language could be stretched (or ignored) >> to produce as close as possible performance results if for example, we write >> a program whose garbage collector have no work to do, assuming that we can >> pre-allocate all required heap space, or that we could somehow work around >> memory safety control points such as, index boundary checking, etc. >> >> - Which one those performance penalty points would exactly be? >> - Which ones would be impossible to workaround? >> - What instructions/operations would be generally speaking comparable? >> >> I know this is a very abstract and theoretical question, I am of course not >> expecting a conclusive/concrete answer to my questions but just some general >> answer, to increase my understanding about language performance while >> providing some pointers to continue my research on the topic. >> >> This will hopefully lead me to a better general understanding on where to >> seek for potential optimisation opportunities within the Go language itself >> vs scenarios where a port to C/C++/Rust would most likely be a better option. > > It is possible to write Go code in which all memory allocation is > explicit (through calls to the new function). Parts of the runtime > package are written that way, for example. However, it's quite hard, > and it's quite easy to make a mistake. It's not really practical to > write real Go code that way, especially since the rest of the standard > library isn't written that way. > > 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/CAOyqgcVPChN%2BHT1h5D6v-BgTMDeHLo4ai6mxiR%2BxaWbnRGAMMA%40mail.gmail.com. -- 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/62E3B9DD-F1EB-4B01-97E0-1A6BBAE6920E%40ix.netcom.com.
Re: [go-nuts] Achieving C/C++/Rust comparable performance with Golang
On Wed, Dec 14, 2022 at 9:57 AM Kursk wrote: > > Go is a high performant garbage collected language, (considered) memory safe > programming language, and as such its performance may not be comparable with > other languages such as C/C++/Rust under certain application scenarios. > > I was wondering, how much of the Go language could be stretched (or ignored) > to produce as close as possible performance results if for example, we write > a program whose garbage collector have no work to do, assuming that we can > pre-allocate all required heap space, or that we could somehow work around > memory safety control points such as, index boundary checking, etc. > > - Which one those performance penalty points would exactly be? > - Which ones would be impossible to workaround? > - What instructions/operations would be generally speaking comparable? > > I know this is a very abstract and theoretical question, I am of course not > expecting a conclusive/concrete answer to my questions but just some general > answer, to increase my understanding about language performance while > providing some pointers to continue my research on the topic. > > This will hopefully lead me to a better general understanding on where to > seek for potential optimisation opportunities within the Go language itself > vs scenarios where a port to C/C++/Rust would most likely be a better option. It is possible to write Go code in which all memory allocation is explicit (through calls to the new function). Parts of the runtime package are written that way, for example. However, it's quite hard, and it's quite easy to make a mistake. It's not really practical to write real Go code that way, especially since the rest of the standard library isn't written that way. 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/CAOyqgcVPChN%2BHT1h5D6v-BgTMDeHLo4ai6mxiR%2BxaWbnRGAMMA%40mail.gmail.com.
[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] 'go run hello.go' taking ~30 seconds on windows
I am guessing it is a dns resolution issue during startup. See the GODEBUG netdns settings. > On Dec 14, 2022, at 11:57 AM, 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/d7957ef7-e3c3-44f7-a6bb-0e870562eb0en%40googlegroups.com. -- 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/03EA3571-4B7C-421D-B42A-D256FAEE6527%40ix.netcom.com.
[go-nuts] Achieving C/C++/Rust comparable performance with Golang
Hi, Go is a high performant garbage collected language, (considered) memory safe programming language, and as such its performance may not be comparable with other languages such as C/C++/Rust under certain application scenarios. I was wondering, how much of the Go language could be stretched (or ignored) to produce as close as possible performance results if for example, we write a program whose garbage collector have no work to do, assuming that we can pre-allocate all required heap space, or that we could somehow work around memory safety control points such as, index boundary checking, etc. - Which one those performance penalty points would exactly be? - Which ones would be impossible to workaround? - What instructions/operations would be generally speaking comparable? I know this is a very abstract and theoretical question, I am of course not expecting a conclusive/concrete answer to my questions but just some general answer, to increase my understanding about language performance while providing some pointers to continue my research on the topic. This will hopefully lead me to a better general understanding on where to seek for potential optimisation opportunities within the Go language itself vs scenarios where a port to C/C++/Rust would most likely be a better option. Thanks in advance. -- 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/fc16bd08-fab3-44fd-82f5-003735426eecn%40googlegroups.com.
[go-nuts] 'go run hello.go' taking ~30 seconds on windows
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/d7957ef7-e3c3-44f7-a6bb-0e870562eb0en%40googlegroups.com.
[go-nuts] Re: Hide Golang Code from Exported package
Hi is there another way as we have to package it as a dll or a lib . But whenever we try using syscall with dll it fails with "bad sweepgen in refill" Is there any other way where we font create a new executable thanks On Monday, December 12, 2022 at 1:34:23 PM UTC+5:30 Brian Candler wrote: > Distribute your library as a grpc server. > https://github.com/hashicorp/go-plugin > > On Monday, 12 December 2022 at 07:56:52 UTC nsing...@gmail.com wrote: > >> Actually i need to share it as an sdk. So any way i can share >> >> On Thursday, December 8, 2022 at 1:13:17 PM UTC+5:30 marc...@gmail.com >> wrote: >> >>> if you produce an executable, nobody sees the actual Go code. >>> build it with: >>> go build -ldflags "-s -w" >>> >>> or you could try to obfuscate it: >>> https://github.com/burrowers/garble >>> >>> or you can make a self-extracting executable >>> >>> >>> Op woensdag 7 december 2022 om 19:09:31 UTC+1 schreef nsing...@gmail.com >>> : >>> Hi All, We are looking for a way to distribute a Golang Package. but We ant to hide the Code which we have written. We went Through Creating A DLL to distribute but it crashes at different point while running. As we have distribute to Both linux and windows . And i found that for linux we can use plugin. But the crash for windows dll after importing the file is concerning for us and its happening at random points in the code also "bad sweepgen in refill". If there is any other way to distribute the code without showing the source code please Tell Thanks Neeraj >>> -- 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/400062eb-f5ec-444b-8782-bdc5670222aen%40googlegroups.com.
