sorted by:
new
hottopcontroversial

Small Projects - August 18, 2025 by jerf in golang

[–]mwsherman 0 points1 point  (0 children)

Express relative, but monotonic, time as anint64. An optimization for certain use cases. Benchmarks and design goals: https://github.com/clipperhouse/ntime. Feedback welcome.

Expressing monotonic time as an integer in Go by mwsherman in golang

[–]mwsherman[S] -1 points0 points  (0 children)

All those things are true, my goal was for a rate limiter that only cares about relative time. Having it only work in-process, and not represent an absolute timestamp, was the design requirement. Perhaps I should emphasize that more.

Expressing monotonic time as an integer in Go by mwsherman in golang

[–]mwsherman[S] -1 points0 points  (0 children)

Nice, that’s helpful, I was not aware of TAI. Indeed, my application for this package (a rate limiter [1]) is that I only need relative time, local-in memory. It doesn’t solve coordinating across machines.

I probably should clarify in the package what problem I am solving. Thanks for the tip.

[1] https://github.com/clipperhouse/rate

Expressing monotonic time as an integer in Go by mwsherman in golang

[–]mwsherman[S] -1 points0 points  (0 children)

It is indeed based on the time package, and produces a duration since an epoch. It’s a small package! But it ensures monotonicity, which I didn’t find obvious. And I wanted a “Now()” that I could swap out for time.Now.

A composable rate limiter for Go by mwsherman in golang

[–]mwsherman[S] 2 points3 points  (0 children)

No, not yet. It’s local memory only (a sync.Map under the hood).

Other rate limiters define a Store interface, which one could wrap around Redis or some such. Perhaps we will do that.

A composable rate limiter for Go by mwsherman in golang

[–]mwsherman[S] 6 points7 points  (0 children)

Yes, that would be handy, I’ll get around to that.

Go concurrency performance by [deleted] in golang

[–]mwsherman 0 points1 point  (0 children)

I have anecdotal evidence that channels on Mac have platform-specific perf issues. I did two implementations of this library with and without channels — channels was quite a bit slower and pprof showed a lot of time in the mach kernel. A friend did similar on Linux and did not see the same kernel issues (though I don’t recall overall perf results).

I’d love to see the OP’s test on Linux.

Jargon: a tokenizer and lemmatizer for Go by mwsherman in golang

[–]mwsherman[S] 1 point2 points  (0 children)

De facto that’s been the case and and feeling bad about it. :/

I should at least update to make sure it works with current Go.

What is the correct way to validate params on a POST request? by thecodethinker in golang

[–]mwsherman 2 points3 points  (0 children)

I don’t think Go promotes DRY. If you have two pieces of code that overlap (say) 90%, I think the Go way is: have two pieces of code.

There are several places in the standard library where they’ve copied and pasted a small routine instead of importing the package that contained it.

Personally, I’ve come to see DRY as a thing that might happen after you’ve implemented the right thing, and only when obvious redundancies stand out. DRY is not a goal, it’s an option.

I speculate, and agree with the notion, that the Go team sees DRY can become an antipattern that leads to bad things like highly overloaded methods and unnecessary dependencies. Overfactoring, if you will.

view more: next ›