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,
t; 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/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com.
--
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 mea
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
>
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 func
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 .
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
e
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. ti
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 proxy
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
https://kinvolk.io/blog/20
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
solutio
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
://github.com/willpoint/treemap
>
> 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 suggesti
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 handl
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 sleeping
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 lik
(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 taste
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 one
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 a
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
ing db/sql 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 ac
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:
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 pr
nd
> allocations. I'm sure that's the root of the problem. But I don't
> understand why the compiler can't figure out that no heap allocation is
> needed. If t doesn't escape when calling t.M(), why can't the compiler work
> out that t.M shouldn't cause t
someone posts a definitive
> 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 *opt
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 cop
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 wrot
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
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 question
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](
> https://emilymaier.net/words
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 overla
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
allo
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 li
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, where
> sharedUnderl
Re-posting to the list.
On Mon, 31 Jul 2017, 14:15 roger peppe, wrote:
> On 30 July 2017 at 08:22, Tristan Colgate wrote:
>
>>
>>
>> On Sat, 29 Jul 2017, 23:59 Shawn Milochik, wrote:
>>
>>>
>>>- You don't need generics to write Kuber
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.
https://godoc.org/k8s.io/client-g
Do you happen to use godep? I think I've had it cause this problem before.
On Thu, 13 Oct 2016 at 03:00 Tong Sun wrote:
>
> On Wed, Oct 12, 2016 at 5:56 PM, Thomas Modeneis wrote:
>
> The main problem seems to be related to go get believe me or not.
>
>
> I kind of agree, in the sense that what
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 I
38 matches
Mail list logo
