[go-nuts] Announce hugot - a chat bot package

Hi All, I'd like to announce hugot. An (hopefully) idiomatic library for building chat bots. It is inspired by net/http, and hopefully let's you build bots up how you want to. I'm particularly interested in feedback on the API. (...and test coverage is next on my list, promise!) Hopefully

Re: [go-nuts] Re: Generics are overrated.

On Sat, 29 Jul 2017, 23:59 Shawn Milochik, wrote: > >- You don't need generics to write Kubernetes. > > I've had no personal need for generics, but k8s client-go is the one case I've seen where I thought they would help, the informers packages in particular.

Re: [go-nuts] Re: Generics are overrated.

Re-posting to the list. On Mon, 31 Jul 2017, 14:15 roger peppe, <rogpe...@gmail.com> wrote: > On 30 July 2017 at 08:22, Tristan Colgate <tcolg...@gmail.com> wrote: > >> >> >> On Sat, 29 Jul 2017, 23:59 Shawn Milochik, <shawn.m...@gmail.com> wrote: >&g

[go-nuts] Re: Generics are overrated.

On Mon, 31 Jul 2017, 18:21 roger peppe, wrote: > > > import hpaInformer informer > > > > myInformer := hpaInformer.New(sharedUnderlyingCacheThing) > > So... to me, the implementation of NewHorizontalPodAutoscalerInformer looks > pretty much exactly like what you've got there,

Re: [go-nuts] Re: Generics and readability

It would be great to hear from those that have written extensive code generation tools as to what changes, if any, Go2 could bring to make code generation easier. Code generation feels more idiomatic to Go. I'm tempted by some kind of package level generics, but I'm terrified that the standard

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

Just read: https://emilymaier.net/words/getting-specific-about-generics/ I think I concur, keep specification of behaviour in interfaces if possible. Contracts overlap too much. If interfaces can do the job, all be it less elegantly, the extra verbosity seems worth it to avoid the feature

Re: [go-nuts] Link: Getting specific about generics

It's a great read, clarified stuff for me. An approach that embraces interfaces feels preferable to me. On Sun, 2 Sep 2018, 09:09 'Charlton Trezevant' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > Link: [Getting specific about generics, by Emily Maier]( >

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

Also, and I think this probably applies to the existing syntax in the design. This example seems like a pathological use of generics. What would be the advantage over just declaring the function takes a Stringer? Am I missing something (presumably this is potentially avoids the interface call

Re: [go-nuts] A thought on contracts

This would disallow contracts on presence and type of fields right? The existing design permits them, and disallowing them feels a little arbitrary. On Tue, 4 Sep 2018, 17:17 roger peppe, wrote: > On 4 September 2018 at 15:41, thwd wrote: > > From the draft proposal I gather two open

Re: [go-nuts] A thought on contracts

Without though, people maybe encouraged to create getters and setters,which is very un-Go. Contracts can match a method explicitly if needed. On Tue, 4 Sep 2018, 17:49 roger peppe, wrote: > On 4 September 2018 at 17:30, Tristan Colgate wrote: > > This would disallow contracts on

Re: [go-nuts] A thought on contracts

One thing that has been occurring to me on this is that it is probably reasonably practical to have a tool infer and update the contracts. The tool could limit itself to a restricted set of statements, without the spec needing to actually limit them directly. On Wed, 5 Sep 2018 at 09:17 thwd

Re: [go-nuts] A thought on contracts

You lose the ability to see changes of contract in your diff (which I think is the thing I most want). On Fri, 7 Sep 2018 at 15:56 Robert Johnstone wrote: > Hello, > > This seems more like a question for tooling. It has already been > discussed that there should be a tool to read a body and

Re: [go-nuts] Re: Why does this struct escape to the heap?

I think this has to do with the pointer reciever, vs the pass by value: func noEscape(r rune, opts *options) bool { f := opts.isDigit return f(r) } opts here does not escape, but in: func escapes(r rune, opts options) bool { f := opts.isDigit return f(r) } opts is copied, so it is the

Re: [go-nuts] Re: Why does this struct escape to the heap?

answer here. > > Thanks... > > > On Thursday, September 6, 2018 at 10:33:17 AM UTC-5, Tristan Colgate wrote: >> >> I think this has to do with the pointer reciever, vs the pass by value: >> >> func noEscape(r rune, opts *options) bool { >> f := opts.

Re: [go-nuts] SQL Interceptor

issue to discuss tracing (which would also facilitate metrics collection): https://github.com/golang/go/issues/18080 On Mon, 10 Sep 2018 at 09:22 Conrad Wood wrote: > On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote: > > There are two existing projects used to achieve simi

Re: [go-nuts] SQL Interceptor

There are two existing projects used to achieve similar goals: https://github.com/ExpansiveWorlds/instrumentedsql https://github.com/gchaincl/sqlhooks native support could probably improve things a little, but this is a very reasonable approach. On Mon, 10 Sep 2018 at 08:59 Conrad Wood wrote:

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

It feels like, so far, all of the attempts to simplify the original design wind up looking more complicated for little benefit (and reduced functionality). Re-using interfaces seems like it would mandate boxing, (or interfaces are no longer interfaces as currently described, which would also be a

Re: [go-nuts] Re: Proposed changes to the Go draft generics design in the light of feedback received

It is not at all obvious that you have sufficient experience of writing Go for anyone to take your, rather disrespectful, comments seriously. Ian has been working on finding a workable model for generic programming in Go for at least 5 years. To many of us, contracts look like a pragmatic

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Operator overloading seems completely antithetical to what most seem to value in Go. Readability is key. Go mostly avoids syntactic sugar (and where it has it, it is often acknowledged as a mistake). To me, the existing contracts design makes it clear when a generic is being used. It should also

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Maybe you mean something like support for linux uprobes? There is some discussion here: https://github.com/golang/go/issues/22008 Google for "golang uprobes" picks up a couple of other links: http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html

Re: [go-nuts] A treemap implemented in go

; Thanks, > > Uzondu > > On Wed, Oct 3, 2018, 09:13 Uzondu Enudeme wrote: > >> Thanks a lot Tristan, >> >> The points you mentioned are really all very important ones. >> >> I'm currently following all your suggestions and would repost the link to >> the

Re: [go-nuts] A treemap implemented in go

A couple of quick observations. This would be more useful as a package than a single program. You could move main into an example/ folder and keep the rest of the content in the top level as a package. Move the explanatory comment up as a Package comment. The standard library includes color

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

But every aspect of that still reads unambiguously in a left to right order. Actually understanding C declarations can be extremely challenging. On Thu, 20 Sep 2018, 06:47 Sathish VJ, wrote: > So, you are saying it is only for readability? > > But even in go we can write convoluted functions

Re: [go-nuts] ticker for poisson processes?

Both use the runtime timers underneath. Ticker requires an extra channel send. Tracking this down was interesting! On Thu, 27 Sep 2018, 14:56 David Wahlstedt, wrote: > I mean that an ordinary go thread executing a sleep instruction may risk > to be starved by the scheduler, so the real

Re: [go-nuts] Package Stutter

Whilst not exaclty the peek of modern tooling, grep is one method of checking where and how your package is used. That's a lot clearer without dot imports. I've never used a dot import, and don't think I have seen one in the wild. Allowing dot imports feels like a bit of a wart (but one that is

Re: [go-nuts] Package Stutter

In the cases of time and context, the stutters appear in a primary type that is important to the package, but rarely appears directly in normal API usage. E.g., time.Now(), context.Background(). Stutter is to be avoided. The package name can provide context. But stutter is preferred to, e.g.

Re: [go-nuts] How to get request url scheme?

On the server side you don't know the scheme used. It isn't part of the request as such. It has to be determined based on the properties of the port that got the request (if you are listening with TLS on a port, the request you got is definitely some flavour of https). If you have a reverse

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

(I'm acutely aware that there's a limit to how useful endless back and forth on this stuff is, and I definitely have to yield on the technical details here, I'll leave the grown up to discuss after this I promise) On Tue, 11 Sep 2018 at 14:26 Axel Wagner wrote: > There is no accounting for

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

On Tue, 11 Sep 2018, 18:12 jimmy frasche, wrote: > Using the interface type to constrain type parameters at compile-time > does not necessarily imply using the interface value to implement > generics at runtime. No, but this does imply that we override what an interface is. They are already

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

I think the point is that by implementing Getter/Setter methods, which are trivially inline-able there's no real downside to skipping fields and just allowing method calls. If it makes it easier to unify contracts and interfaces, I think that may be a hit worth taking (though I still say, getters

Re: [go-nuts] Re: Should IP.DefaultMask() exist in today's Internet?

Just on a point of clarity. DefaultMask is returning the mask associates with the network class. RFC1918 specifies a bunch of class A,B and C networks for private use. E.g. 192.168/16 is a set of 256 class C networks. The correct netmask for one of those class Cs is 255.255.255.0 (/24). So the

Re: [go-nuts] non-local return?

I've never seen a coding guide advocate for setjmp/longjump . And having worked a bit in scheme with first class continuations, they have their beauty, but if you want to understand your code a year after you wrote it, I wouldn't personally recommend it. I don't miss either of these things in Go .

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

While pure TDD as defined by its canonical text can be frustrating and time consuming, simply not writing tests is not really a defensible position, and definitely not one that Go, or any other language, should attempt to make easier. Writing testable code, and writing tests, does not have to

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

is 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com. -- Tristan Colgate-McF

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

It's also worth pointing out that a nil pointer value can still be useful. You can still call methods on it. On Sat, 15 Feb 2020, 13:13 , wrote: > Woah! that's a killer reason, the one I was searching for. Thanks for > pointing it out, as you have saved me a lot of time discarding the proposal

Re: [go-nuts] Generics - please provide real life problems

If Go with generics wax released tomorrow I have about 8 kubernetes controllers that I'd be porting to use a type safe version of the work queue to. This isn't theoretical, I will do this week 1 of generics being available. It is all production code. On Thu, 24 Dec 2020, 06:15 Martin Hanson,