[go-nuts] Re: Intentionally omitting requires in go.mod - alternative to multi-module repository?

[Leigh McCulloch]

I'm a user of the sentry-go SDK who has been impacted by the large number 
of dependencies in the past.

>Independently, if your users have automated tools that are issuing 
false-positive CVE warnings based on the module graph instead of the 
package-import graph, you may want to suggest that they file issues against 
those tools.

Does using the package-import graph capture the full picture of how a 
module impacts importers of the module. My understanding – maybe incorrect 
or out-dated – is that importing a module still brings that modules 
complete dependency graph into the dependency resolution process. Anyone 
using dependencies imported will be limited by the minimum versions defined 
in sentry-go SDK or any transitive dependency through sentry-go. Even if 
their go.mod is simpler on the surface, an SDK with a large and far 
reaching dependency graph can still impact other projects.

Bryan, is there a good example of how to use the go tool to provide details 
of the package-import graph? I would normally use go mod graph and go mod 
why which as I understand both are limited to the module graph.

Thanks!
Leigh

On Friday, January 21, 2022 at 1:31:12 PM UTC-8 Bryan C. Mills wrote:

> On Thursday, January 13, 2022 at 12:45:13 PM UTC-5 rhcar...@gmail.com 
> wrote:
>
>> Hello fellow Gophers!
>>
>> I help maintain an SDK module 
>>  that includes 
>> packages that provide middleware to different web frameworks (e.g. echo 
>> ).
>>
>> The SDK started out as a single module in a Git repository, and we have 
>> considered 
>> and hesitated splitting it into multiple modules 
>>  in a single 
>> repository because of the implications that it has on maintenance, 
>> development, testing and release processes.
>>
>> The root package implements the core functionality of the SDK and has no 
>> external dependencies, it only needs the standard library. That's what most 
>> people need. The other packages each depend on a web framework module, and 
>> downstream users typically only need to use one of those packages and do 
>> not want to bother about the others.
>>
>> The current `/go.mod` file is littered with dependencies to many web 
>> frameworks 
>> 
>>  
>> and their dependencies, and that has caused problems and confusion to 
>> our downstream users , 
>> especially when one of those dependencies end up flagged by tools like 
>> Dependabot as containing a CVE. (Code security scanners seem to typically 
>> operate on the Go module level and not at the package level, so they often 
>> report problems even though the affected module/package is not part of the 
>> final build list of the main package.)
>>
>
> As you noted, this is one of the use-cases we had in mind for module graph 
> pruning in Go 1.17.
> So one option is to run 'go mod tidy -go=1.17' to upgrade your module to 
> support pruning, so that the consumers of your module won't themselves need 
> to download irrelevant dependencies. That shouldn't harm any of your users 
> on older Go versions (we designed it to be backward-compatible), although 
> they won't see the benefits of pruning until they upgrade.
>
> Independently, if your users have automated tools that are issuing 
> false-positive CVE warnings based on the module graph instead of the 
> package-import graph, you may want to suggest that they file issues against 
> those tools. Ideally automated tools ought to be using the package-import 
> graph instead of the module graph; however, if that's too involved they 
> could still get a better approximation by consulting the `go.sum` file for 
> the main module. (Modules that contribute packages relevant to the build 
> will have source-code checksums in the `go.sum` file; modules that are in 
> the module graph but not otherwise relevant will have only `/go.mod` 
> checksums.)
>
>
> I've been trying to find a way to eliminate the problems of the current 
>> single-module-per-repo setup while avoiding the implications of going 
>> multi-module-per-repo, as we have limited resources to maintain the SDK.
>>
>> The recent idea I had was to simply omit `require` entries in the 
>> `/go.mod` file 
>> , 
>> essentially making the module "untidy" (as in `go mod tidy` would 
>> re-introduce the missing requires), but I haven't found any mention to 
>> that approach on the Internet.
>>
>
> We have tests of cmd/go behavior in that kind of configuration, but we 
> don't recommend it. Leaving your module untidy makes builds of your 
> packages less reproducible for users, and in some cases can also cause 
> extra work for the `go` command to resolve the latest versions of 

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[envee]

Thanks Kurtis and Robert.

My use-case is for a telecommunications application (HTTP/2 client, 5G 
client to be precise) which needs to send 5G (HTTP/2) requests to a server 
at a configurable rate (TPS). 
While the telecom industry very commonly use the word TPS (Transactions Per 
Second), I would like to control the rate within the second i.e. if the TPS 
is to be 2000, then I would like to spread these 2000 transactions (HTTP/2 
requests) over 1 second uniformly i.e. 1 request every 500 mico-seconds 
which will then result in 2000 requests in that 1 second.
I believed that by using a time.Ticker to fire every 500 micro-seconds, I 
would be able to achieve this outcome.

Is there any other way you could suggest I do this using Go ? 

On Monday, 31 January 2022 at 15:17:23 UTC+11 ren...@ix.netcom.com wrote:

> Pretty much what Kurtis said. Low interval timers usually require 
> specialized constructs if not a real time OS to efficiently (or even at 
> all). 
>
> On Jan 30, 2022, at 9:16 PM, envee  wrote:
>
> Thanks, but I am not sure how that reference solves the issue ?
>
> Or are you suggesting that the only way is to use Cgo and invoke usleep to 
> get very close to the Ticker duration specified ?
>
> On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:
>
>> See https://github.com/golang/go/issues/27707
>>
>> On Jan 30, 2022, at 5:50 PM, envee  wrote:
>>
>> Hi All,
>>
>> I understand this issue has been discussed in the past, and I have seen a 
>> few comments from Ian and Russ Cox about this topic, but I could not arrive 
>> at a conclusion about how I can make the time.Ticker send me ticks at 
>> atleast close to the Ticker duration I specify. At the moment, I am seeing 
>> ticks being sent at way over the specified duration especially when I have 
>> sub-millisecond durations. 
>> With 1ms duration, the ticker seems to be quite close to the duration 
>> (maybe within +/-5%). I would be happier if it were within 1%, but I can 
>> handle that.
>>
>> With 1 micro-second duration, the ticker sends ticks nearly 4 times 
>> slower than expected.
>>
>> Here is my sample code
>> "
>> ti := time.NewTicker(1 * time.Millisecond)
>> start := time.Now()
>> for i := 0; i < 1000; i++ {
>> <-ti.C
>> }
>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>> "
>>
>> The output is usually close to 1 second as expected (close to) when using 
>> 1ms duration.
>> elapsed time = 1.000159338s
>>
>>
>> My code for the microsecond test is :
>> "
>> ti := time.NewTicker(1 * time.Microsecond)
>> start := time.Now()
>> for i := 0; i < 100; i++ {
>> <-ti.C
>> }
>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>> "
>>
>> With this, I get the following output which shows the elapsed time close 
>> to 4 seconds :
>> elapsed time = 4.796662856s
>>
>> *Is there anyway, I can ensure ticks are sent at approximately within 5% 
>> of my specified duration ?*
>>
>> I understand from time.Ticker docs that ticks will be lost if the ticker 
>> handler cannot keep up with the ticker time.
>>
>> In the simple code above, I am literally doing very minimal work in each 
>> loop iteration and that is about checking the loop condition.
>> So I am not sure why ticks are being lost ?
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5f55ccf9-1478-4490-a8f4-a35a5764721dn%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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/efa204c2-092f-46e1-abe4-8aa5c502d986n%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/3f9d1c36-4820-4555-a5f3-9721e661530bn%40googlegroups.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Robert Engels]

Pretty much what Kurtis said. Low interval timers usually require specialized 
constructs if not a real time OS to efficiently (or even at all). 

> On Jan 30, 2022, at 9:16 PM, envee  wrote:
> 
> Thanks, but I am not sure how that reference solves the issue ?
> Or are you suggesting that the only way is to use Cgo and invoke usleep to 
> get very close to the Ticker duration specified ?
> 
>> On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:
>> See https://github.com/golang/go/issues/27707
>> 
 On Jan 30, 2022, at 5:50 PM, envee  wrote:
 
>>> Hi All,
>> 
>>> I understand this issue has been discussed in the past, and I have seen a 
>>> few comments from Ian and Russ Cox about this topic, but I could not arrive 
>>> at a conclusion about how I can make the time.Ticker send me ticks at 
>>> atleast close to the Ticker duration I specify. At the moment, I am seeing 
>>> ticks being sent at way over the specified duration especially when I have 
>>> sub-millisecond durations. 
>>> With 1ms duration, the ticker seems to be quite close to the duration 
>>> (maybe within +/-5%). I would be happier if it were within 1%, but I can 
>>> handle that.
>>> 
>>> With 1 micro-second duration, the ticker sends ticks nearly 4 times slower 
>>> than expected.
>>> 
>>> Here is my sample code
>>> "
>>> ti := time.NewTicker(1 * time.Millisecond)
>>> start := time.Now()
>>> for i := 0; i < 1000; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>> 
>>> The output is usually close to 1 second as expected (close to) when using 
>>> 1ms duration.
>>> elapsed time = 1.000159338s
>>> 
>>> 
>>> My code for the microsecond test is :
>>> "
>>> ti := time.NewTicker(1 * time.Microsecond)
>>> start := time.Now()
>>> for i := 0; i < 100; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>> 
>>> With this, I get the following output which shows the elapsed time close to 
>>> 4 seconds :
>>> elapsed time = 4.796662856s
>>> 
>>> Is there anyway, I can ensure ticks are sent at approximately within 5% of 
>>> my specified duration ?
>>> 
>>> I understand from time.Ticker docs that ticks will be lost if the ticker 
>>> handler cannot keep up with the ticker time.
>>> 
>>> In the simple code above, I am literally doing very minimal work in each 
>>> loop iteration and that is about checking the loop condition.
>>> So I am not sure why ticks are being lost ?
>> 
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/5f55ccf9-1478-4490-a8f4-a35a5764721dn%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/efa204c2-092f-46e1-abe4-8aa5c502d986n%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/9070D322-8F84-4033-8205-DAF6CE0A9D18%40ix.netcom.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Kurtis Rader]

On Sun, Jan 30, 2022 at 7:16 PM envee  wrote:

> Thanks, but I am not sure how that reference solves the issue ?
> Or are you suggesting that the only way is to use Cgo and invoke usleep to
> get very close to the Ticker duration specified ?
>
> On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:
>
>> See https://github.com/golang/go/issues/27707
>>
>
The reference to that issue does not solve your problem. It illustrates
that this issue has been noted, and discussed, for at least three years. It
hasn't been resolved because a solution is difficult. It would help if you
provided a concrete example why this matters. As has been done in the
referenced issue.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-SPTi8Lv%2BQwWNPxLv%3DacqxAEE1Ra6_AMV2rxp%3DD1JhaA%40mail.gmail.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[envee]

Thanks, but I am not sure how that reference solves the issue ?
Or are you suggesting that the only way is to use Cgo and invoke usleep to 
get very close to the Ticker duration specified ?

On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:

> See https://github.com/golang/go/issues/27707
>
> On Jan 30, 2022, at 5:50 PM, envee  wrote:
>
> Hi All,
>
> I understand this issue has been discussed in the past, and I have seen a 
> few comments from Ian and Russ Cox about this topic, but I could not arrive 
> at a conclusion about how I can make the time.Ticker send me ticks at 
> atleast close to the Ticker duration I specify. At the moment, I am seeing 
> ticks being sent at way over the specified duration especially when I have 
> sub-millisecond durations. 
> With 1ms duration, the ticker seems to be quite close to the duration 
> (maybe within +/-5%). I would be happier if it were within 1%, but I can 
> handle that.
>
> With 1 micro-second duration, the ticker sends ticks nearly 4 times slower 
> than expected.
>
> Here is my sample code
> "
> ti := time.NewTicker(1 * time.Millisecond)
> start := time.Now()
> for i := 0; i < 1000; i++ {
> <-ti.C
> }
> fmt.Printf("elapsed time = %v\n", time.Since(start))
> "
>
> The output is usually close to 1 second as expected (close to) when using 
> 1ms duration.
> elapsed time = 1.000159338s
>
>
> My code for the microsecond test is :
> "
> ti := time.NewTicker(1 * time.Microsecond)
> start := time.Now()
> for i := 0; i < 100; i++ {
> <-ti.C
> }
> fmt.Printf("elapsed time = %v\n", time.Since(start))
> "
>
> With this, I get the following output which shows the elapsed time close 
> to 4 seconds :
> elapsed time = 4.796662856s
>
> *Is there anyway, I can ensure ticks are sent at approximately within 5% 
> of my specified duration ?*
>
> I understand from time.Ticker docs that ticks will be lost if the ticker 
> handler cannot keep up with the ticker time.
>
> In the simple code above, I am literally doing very minimal work in each 
> loop iteration and that is about checking the loop condition.
> So I am not sure why ticks are being lost ?
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5f55ccf9-1478-4490-a8f4-a35a5764721dn%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/efa204c2-092f-46e1-abe4-8aa5c502d986n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Henry]

And there is that ... LOL. I normally ignore "goto", but yes it can be 
turned into a looping construct. When refactoring code that uses "goto", I 
would try to eliminate "goto" first. If it isn't possible, then the 
execution flow must be so complex that it doesn't need to be broken down 
further. 

On Sunday, January 30, 2022 at 9:24:15 PM UTC+7 Brian Candler wrote:

> On Sunday, 30 January 2022 at 11:31:25 UTC Henry wrote:
>
>> In Go, there is only one looping construct, which is the "for" keyword.
>>
>
> Don't forget "goto" :-)
>
> << ducks >>
>

-- 
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/108ce9eb-2378-4d78-a712-7986280cd710n%40googlegroups.com.

Re: [go-nuts] Why Go allow function with unused arguments?

['Dan Kortschak' via golang-nuts]

On Sun, 2022-01-30 at 13:47 -0800, Sean Liao wrote:
> By enforcing blanks, you'd lose the chance to name them something
> useful to tell the reader why they're ignored.
> eg:
> // why are the last 2 args ignored??
> handleX = func(foo, bar, _, _ string) string { return foo + bar }
>

Probably more significantly at this stage, it's a breaking change to
the language.


-- 
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/4de73f825a36057e56400544ebd3600afe66f216.camel%40kortschak.io.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Robert Engels]

See https://github.com/golang/go/issues/27707

> On Jan 30, 2022, at 5:50 PM, envee  wrote:
> 
> Hi All,
> I understand this issue has been discussed in the past, and I have seen a few 
> comments from Ian and Russ Cox about this topic, but I could not arrive at a 
> conclusion about how I can make the time.Ticker send me ticks at atleast 
> close to the Ticker duration I specify. At the moment, I am seeing ticks 
> being sent at way over the specified duration especially when I have 
> sub-millisecond durations. 
> With 1ms duration, the ticker seems to be quite close to the duration (maybe 
> within +/-5%). I would be happier if it were within 1%, but I can handle that.
> 
> With 1 micro-second duration, the ticker sends ticks nearly 4 times slower 
> than expected.
> 
> Here is my sample code
> "
> ti := time.NewTicker(1 * time.Millisecond)
> start := time.Now()
> for i := 0; i < 1000; i++ {
> <-ti.C
> }
> fmt.Printf("elapsed time = %v\n", time.Since(start))
> "
> 
> The output is usually close to 1 second as expected (close to) when using 1ms 
> duration.
> elapsed time = 1.000159338s
> 
> 
> My code for the microsecond test is :
> "
> ti := time.NewTicker(1 * time.Microsecond)
> start := time.Now()
> for i := 0; i < 100; i++ {
> <-ti.C
> }
> fmt.Printf("elapsed time = %v\n", time.Since(start))
> "
> 
> With this, I get the following output which shows the elapsed time close to 4 
> seconds :
> elapsed time = 4.796662856s
> 
> Is there anyway, I can ensure ticks are sent at approximately within 5% of my 
> specified duration ?
> 
> I understand from time.Ticker docs that ticks will be lost if the ticker 
> handler cannot keep up with the ticker time.
> 
> In the simple code above, I am literally doing very minimal work in each loop 
> iteration and that is about checking the loop condition.
> So I am not sure why ticks are being lost ?
> -- 
> 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/5f55ccf9-1478-4490-a8f4-a35a5764721dn%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/D5DF77AD-1E68-48AE-883D-9423AA6ABF2F%40ix.netcom.com.

[go-nuts] Issues when using time.Ticker microsecond duration

[envee]

Hi All,
I understand this issue has been discussed in the past, and I have seen a 
few comments from Ian and Russ Cox about this topic, but I could not arrive 
at a conclusion about how I can make the time.Ticker send me ticks at 
atleast close to the Ticker duration I specify. At the moment, I am seeing 
ticks being sent at way over the specified duration especially when I have 
sub-millisecond durations. 
With 1ms duration, the ticker seems to be quite close to the duration 
(maybe within +/-5%). I would be happier if it were within 1%, but I can 
handle that.

With 1 micro-second duration, the ticker sends ticks nearly 4 times slower 
than expected.

Here is my sample code
"
ti := time.NewTicker(1 * time.Millisecond)
start := time.Now()
for i := 0; i < 1000; i++ {
<-ti.C
}
fmt.Printf("elapsed time = %v\n", time.Since(start))
"

The output is usually close to 1 second as expected (close to) when using 
1ms duration.
elapsed time = 1.000159338s


My code for the microsecond test is :
"
ti := time.NewTicker(1 * time.Microsecond)
start := time.Now()
for i := 0; i < 100; i++ {
<-ti.C
}
fmt.Printf("elapsed time = %v\n", time.Since(start))
"

With this, I get the following output which shows the elapsed time close to 
4 seconds :
elapsed time = 4.796662856s

*Is there anyway, I can ensure ticks are sent at approximately within 5% of 
my specified duration ?*

I understand from time.Ticker docs that ticks will be lost if the ticker 
handler cannot keep up with the ticker time.

In the simple code above, I am literally doing very minimal work in each 
loop iteration and that is about checking the loop condition.
So I am not sure why ticks are being lost ?

-- 
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/5f55ccf9-1478-4490-a8f4-a35a5764721dn%40googlegroups.com.

[go-nuts] behaviour (issue) of time.Ticker microsecond duration ticks

[envee]

Hi All,
I understand this issue has been discussed in the past, and I have seen a 
few comments from Ian and Russ Cox about this topic, but I could not arrive 
at a conclusion about how I can make the time.Ticker send me ticks at 
atleast close to the Ticker duration I specify. At the moment, I am seeing 
ticks being sent at way over the specified duration especially when I have 
sub-millisecond durations. 
With 1ms duration, the ticker seems to be quite close to the duration 
(maybe within +/-5%). I would be happier if it were within 1%, but I can 
handle that.

With 1 micro-second duration, the ticker sends ticks nearly 4 times slower 
than expected.

Here is my sample code
"
ti := time.NewTicker(1 * time.Millisecond)
start := time.Now()
for i := 0; i < 1000; i++ {
<-ti.C
}
fmt.Printf("elapsed time = %v\n", time.Since(start))
"

The output is usually close to 1 second as expected (close to) when using 
1ms duration.
elapsed time = 1.000159338s

But when I change the Ticker duration to 1 micro-second, I get the 
following output which shows the elapsed time close to 4 seconds:
elapsed time = 4.796662856s 
*Is there anyway, I can ensure ticks are sent at approximately within 5% of 
my specified duration ?*

I understand from time.Ticker docs that ticks will be lost if the ticker 
handler cannot keep up with the ticker time.

In the simple code above, I am literally doing very minimal work in each 
loop iteration and that is about checking the loop condition.
So I am not sure why ticks are being lost ?





-- 
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/7aaa580e-cdcc-4217-adb3-f86ffa752160n%40googlegroups.com.

Re: [go-nuts] Why Go allow function with unused arguments?

[Sean Liao]

By enforcing blanks, you'd lose the chance to name them something useful to 
tell the reader why they're ignored.
eg:
// why are the last 2 args ignored??
handleX = func(foo, bar, _, _ string) string { return foo + bar }

On Sunday, January 30, 2022 at 10:21:11 PM UTC+1 ren...@ix.netcom.com wrote:

> To the ops point, wouldn’t it be better to cause an error for unused 
> parameters unless they use the blank identifier?
>
> > On Jan 30, 2022, at 2:09 PM, 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
> > 
> > On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
> >> Hello,
> >> 
> >> This is a question from ignorant in the meters of compilers and
> >> mediocre Go users at best, so it may be stupid.
> >> 
> >> I really like that in Go unused variable or import is compiler time
> >> error. As such I wonder why function like
> >>> func funTest(x int) int {
> >>> return 3
> >>> }
> >> is allowed? I would guess that it is possible to check if function
> >> argument is used in function body or not, so it seem plausible to
> >> forbid it.
> >> 
> >> Again, it maybe a stupid question from ignorant person. I have a lot
> >> things to learn about Go, but I'm stuck in learning about Unicode and
> >> UFT-8, so I guess it will be a long time before I can go back to
> >> learning proper Go. I read FAQ and I didn't remember answer to this
> >> question from it. This is my excuse for asking this question.
> >> 
> >> Best regards,
> >> Kamil Ziemian
> > 
> > It is necessary for methods to sometimes have parameters that are not
> > used in order for the type to satisfy an interface. Similarly, if
> > function values are being passed around the signatures will need to
> > match even if the parameters are not being used.
> > 
> > It is possible to use the blank identifier in these cases to signal
> > that a parameter is not being used and that can be linted for.
> > 
> > See https://github.com/golang/go/issues/39118 for discussion on a
> > proposal relating to this.
> > 
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io
> .
>

-- 
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/5d91a708-e83c-4964-b6b1-7c7f6e55ce43n%40googlegroups.com.

Re: [go-nuts] Why Go allow function with unused arguments?

[Robert Engels]

To the ops point, wouldn’t it be better to cause an error for unused parameters 
unless they use the blank identifier?

> On Jan 30, 2022, at 2:09 PM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
>> Hello,
>> 
>> This is a question from ignorant in the meters of compilers and
>> mediocre Go users at best, so it may be stupid.
>> 
>> I really like that in Go unused variable or import is compiler time
>> error. As such I wonder why function like
>>> func funTest(x int) int {
>>>return 3
>>> }
>> is allowed? I would guess that it is possible to check if function
>> argument is used in function body or not, so it seem plausible to
>> forbid it.
>> 
>> Again, it maybe a stupid question from ignorant person. I have a lot
>> things to learn about Go, but I'm stuck in learning about Unicode and
>> UFT-8, so I guess it will be a long time before I can go back to
>> learning proper Go. I read FAQ and I didn't remember answer to this
>> question from it. This is my excuse for asking this question.
>> 
>> Best regards,
>> Kamil Ziemian
> 
> It is necessary for methods to sometimes have parameters that are not
> used in order for the type to satisfy an interface. Similarly, if
> function values are being passed around the signatures will need to
> match even if the parameters are not being used.
> 
> It is possible to use the blank identifier in these cases to signal
> that a parameter is not being used and that can be linted for.
> 
> See https://github.com/golang/go/issues/39118 for discussion on a
> proposal relating to this.
> 
> 
> -- 
> 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/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io.

-- 
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/BE2F9AE9-AA7B-4A6C-996C-DB88D5E8C956%40ix.netcom.com.

Re: [go-nuts] Why Go allow function with unused arguments?

['Dan Kortschak' via golang-nuts]

On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
> Hello,
>
> This is a question from ignorant in the meters of compilers and
> mediocre Go users at best, so it may be stupid.
>
> I really like that in Go unused variable or import is compiler time
> error. As such I wonder why function like
> > func funTest(x int) int {
> > return 3
> > }
> is allowed? I would guess that it is possible to check if function
> argument is used in function body or not, so it seem plausible to
> forbid it.
>
> Again, it maybe a stupid question from ignorant person. I have a lot
> things to learn about Go, but I'm stuck in learning about Unicode and
> UFT-8, so I guess it will be a long time before I can go back to
> learning proper Go. I read FAQ and I didn't remember answer to this
> question from it. This is my excuse for asking this question.
>
> Best regards,
> Kamil Ziemian

It is necessary for methods to sometimes have parameters that are not
used in order for the type to satisfy an interface. Similarly, if
function values are being passed around the signatures will need to
match even if the parameters are not being used.

It is possible to use the blank identifier in these cases to signal
that a parameter is not being used and that can be linted for.

See https://github.com/golang/go/issues/39118 for discussion on a
proposal relating to this.


-- 
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/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io.

[go-nuts] Why Go allow function with unused arguments?

[Kamil Ziemian]

Hello,

This is a question from ignorant in the meters of compilers and mediocre Go 
users at best, so it may be stupid.

I really like that in Go unused variable or import is compiler time error. 
As such I wonder why function like
> func funTest(x int) int {
> return 3
> }
is allowed? I would guess that it is possible to check if function argument 
is used in function body or not, so it seem plausible to forbid it.

Again, it maybe a stupid question from ignorant person. I have a lot things 
to learn about Go, but I'm stuck in learning about Unicode and UFT-8, so I 
guess it will be a long time before I can go back to learning proper Go. I 
read FAQ and I didn't remember answer to this question from it. This is my 
excuse for asking this question.

Best regards,
Kamil Ziemian

-- 
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/fda89503-fde5-4b5b-80c3-50e74da1dc51n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Tim Hardcastle]

True, I don't say that meaningful names can entirely replace comments, just 
that comments can't replace the sort of meaningful if verbose names that OP 
objects to in point (1).

A lot must depend on the personal equation, how well one reads chunks of 
camelCase, how well one reads abbreviations, how good one's memory is, how 
fast one types, etc. Personally I find I just mess up less since I've 
learned to be more verbose.

On Saturday, January 29, 2022 at 9:00:49 AM UTC-8 david@gmail.com wrote:

> On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle  
> wrote:
>
>> Agree with Rudolf on point 2. Long meaningful variable/function names are 
>> good. Comments become obsolete, they become detached from their code, 
>> they're only used to explain the name of the variable once and then you're 
>> left with something than reads
>>
>> // urn contains the userlist
>> fxn := rx (frn)
>>
>>  Now that editors have autocomplete to make up for my meagre typing 
>> speed, you bet your ass I'm going to have [eg from current project] a local 
>> variable called lastTokenWasColon and a method called addWordsToParser. 
>> Because knowing exactly what they do when I need to modify or debug saves 
>> me so much time and trouble. (Perhaps this varies from person to person. If 
>> my memory is poorer than yours, it has more of an upside for me than for 
>> you.)
>>
>
> There's a lot of middle-ground between a three-letter variable or 
> function-name and encoding the whole doc-comment for a function or variable 
> in its name.
> Humans only have so much working memory, once a name gets long enough we 
> start dropping parts of the name and it tends to be stuff in the middle 
> that gets dropped.
>
> If you have a parser type, and a variable with that type, often, it would 
> be better to have an addWords() method on the parser type. Then if you also 
> need a special-case addWord() it's easy to tell what's going on.
>
> I try to have meaningful names, but beyond some threshold, but I try to 
> prevent things from being redundant with the types involved (the entire 
> function signature and type of the variable).
>
> Also, comments are not about just describing what something is. (those are 
> the least useful types of comments) They're also quite useful for 
> describing what's being attempted, what corner-cases are being addressed 
> and if there's any tricky logic that needs to be handled. Additionally, 
> IMO, just about any function or method should have a doc-comment explaining 
> what it expects. (helpers under ~3 lines may be exempt)
>
>>
>> And is there a better solution to the problem in point 1 than to break 
>> the function down into lots of little functions *with meaningful names*? 
>> (If the names (and pieces) aren't meaningful you've only technically broken 
>> it down.)
>>
>> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>>
>>> > 2) Long variable names.
>>>
>>> Where I work (not in Go), writing comments is frowned upon. That 
>>> includes "docblock" style comments. If a function needs to be documented, 
>>> it means the implementation is too complex and must be broken apart to 
>>> reduce cyclomatic or whatever perceived complexity. Also uncle bob told us 
>>> that functions should never be longer than 2-3 lines of code, so it should 
>>> be enough to look at the source code to see what it does. That's the 
>>> general sentiment in my team.
>>> Comments are considered sign of "un"clean code.
>>>
>>> So we use long variable and function names to make the code self 
>>> documenting. (Hint: it doesn't)
>>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>>> trend many years ago. (ie: hungarian notation)
>>>
>>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>>
 1) Long functions that go on forever and contain long lambdas and 8 
 levels of indentation.

 2) Long variable names.

 3) Variable names which include the type of the variable.

 4) Packages whose name contain the word '/pkg/'

 5) Repos which contain the prefix go-

 6) Code where almost every line prefixed by `_, _ =`
 and the underscores won't go away when you wipe your screen


 -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%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 

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Brian Candler]

On Sunday, 30 January 2022 at 11:31:25 UTC Henry wrote:

> In Go, there is only one looping construct, which is the "for" keyword.
>

Don't forget "goto" :-)

<< ducks >>

-- 
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/f9180ffb-c3b2-4652-ae50-65420ba2e6b8n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Henry]

Comments are useful to communicate what is not already apparent in your 
code. Sometimes comments may help you find bugs in your algorithms. On the 
other hand, keep your comments terse and not longer than what is necessary. 
Respect other people's time. 

Long names are not necessarily better. It is more important to have names 
that communicate your intent well and those names are not necessarily long. 
Any name that is longer than three words is usually too long.

As for long functions, my personal rule is that when you have more than one 
looping construct in a function, it is time to break it down. In Go, there 
is only one looping construct, which is the "for" keyword.

More importantly, know your "rules" and when to break them. They are not 
immutable. 

On Sunday, January 30, 2022 at 12:00:49 AM UTC+7 david@gmail.com wrote:

> On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle  
> wrote:
>
>> Agree with Rudolf on point 2. Long meaningful variable/function names are 
>> good. Comments become obsolete, they become detached from their code, 
>> they're only used to explain the name of the variable once and then you're 
>> left with something than reads
>>
>> // urn contains the userlist
>> fxn := rx (frn)
>>
>>  Now that editors have autocomplete to make up for my meagre typing 
>> speed, you bet your ass I'm going to have [eg from current project] a local 
>> variable called lastTokenWasColon and a method called addWordsToParser. 
>> Because knowing exactly what they do when I need to modify or debug saves 
>> me so much time and trouble. (Perhaps this varies from person to person. If 
>> my memory is poorer than yours, it has more of an upside for me than for 
>> you.)
>>
>
> There's a lot of middle-ground between a three-letter variable or 
> function-name and encoding the whole doc-comment for a function or variable 
> in its name.
> Humans only have so much working memory, once a name gets long enough we 
> start dropping parts of the name and it tends to be stuff in the middle 
> that gets dropped.
>
> If you have a parser type, and a variable with that type, often, it would 
> be better to have an addWords() method on the parser type. Then if you also 
> need a special-case addWord() it's easy to tell what's going on.
>
> I try to have meaningful names, but beyond some threshold, but I try to 
> prevent things from being redundant with the types involved (the entire 
> function signature and type of the variable).
>
> Also, comments are not about just describing what something is. (those are 
> the least useful types of comments) They're also quite useful for 
> describing what's being attempted, what corner-cases are being addressed 
> and if there's any tricky logic that needs to be handled. Additionally, 
> IMO, just about any function or method should have a doc-comment explaining 
> what it expects. (helpers under ~3 lines may be exempt)
>
>>
>> And is there a better solution to the problem in point 1 than to break 
>> the function down into lots of little functions *with meaningful names*? 
>> (If the names (and pieces) aren't meaningful you've only technically broken 
>> it down.)
>>
>> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>>
>>> > 2) Long variable names.
>>>
>>> Where I work (not in Go), writing comments is frowned upon. That 
>>> includes "docblock" style comments. If a function needs to be documented, 
>>> it means the implementation is too complex and must be broken apart to 
>>> reduce cyclomatic or whatever perceived complexity. Also uncle bob told us 
>>> that functions should never be longer than 2-3 lines of code, so it should 
>>> be enough to look at the source code to see what it does. That's the 
>>> general sentiment in my team.
>>> Comments are considered sign of "un"clean code.
>>>
>>> So we use long variable and function names to make the code self 
>>> documenting. (Hint: it doesn't)
>>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>>> trend many years ago. (ie: hungarian notation)
>>>
>>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>>
 1) Long functions that go on forever and contain long lambdas and 8 
 levels of indentation.

 2) Long variable names.

 3) Variable names which include the type of the variable.

 4) Packages whose name contain the word '/pkg/'

 5) Repos which contain the prefix go-

 6) Code where almost every line prefixed by `_, _ =`
 and the underscores won't go away when you wipe your screen


 -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com
>>  
>>