Daniel Smith

On a long sabbatical.

Formerly Sr. Staff Software Engineer at Google. Kubernetes founding team member.

[Daniel Smith @originalavalamp]

@KarlKFI No worries, I totally understand the frustration, I just thought some explanation might make it sting less, I didn't mean to give you a hard time :)

[Daniel Smith @originalavalamp]

@KarlKFI No worries, I don't care about the code a decade later, I'm just reacting to the lack of nuance, which I guess is a silly thing to do on Twitter :)

[Daniel Smith @originalavalamp]

@KarlKFI Yes, producer can't send on a closed channel, but I don't think you can deduce your position from that fact. The Stop() method needn't (likely shouldn't) be the thing that closes the channel.

[Daniel Smith @originalavalamp]

@KarlKFI I'm not really defending the watch.Interface, which I'm sure can be improved, I'm mostly just observing that code isolated from the rest of the system generally isn't objectively bad or good, but is rather fit for a purpose or not.

[Daniel Smith @originalavalamp]

@KarlKFI Do you have a 2014 or earlier source on that convention? :) But even if you do, it wouldn't have mattered, I learned go in isolation prior to go1.0, and the rest of the team hadn't used go at all prior to Kubernetes.

[Daniel Smith @originalavalamp]

@KarlKFI Most interface changes trade one such tempting misuse for another. And at the time, it was certainly not worth spending days or weeks to make a bullet-proof interface.

[Daniel Smith @originalavalamp]

@KarlKFI Sounds like FakeWatcher was written to only exercise a certain set of scenarios and things spiraled from there. That happens a lot with code.

[Daniel Smith @originalavalamp]

@KarlKFI Few interfaces necessarily lack that property.

[Daniel Smith @originalavalamp]

@KarlKFI I don't believe my implementation had such a problem, but I haven't looked in a long time, maybe it grew one. The observation was that both sides have to do the same cleanup no matter which side issues the stop, so it wasn't necessary to have separate stop functions for both.

[Daniel Smith @originalavalamp]

@KarlKFI I wrote that before context was a thing. The intention was either side could call stop and it was safe to call multiple times. Once stopped there may still be items to drain, but generally that wasn't important because the client just started over with the last RV it saw anyway.

[Daniel Smith @originalavalamp]

@IanColdwater But to be extra clear, apiserver definitely existed, even in the first prototype.

[Daniel Smith @originalavalamp]

@IanColdwater (the client library was scrambled because I wasn't clear on what called what when I split the prototype into separate packages. It was many years before that mistake got fixed.)

[Daniel Smith @originalavalamp]

@bwplotka @RiRa12621 @the_sttts Everything is tradeoffs, keeping working code working is (and should be) their top priority. What I said wasn't meant as a criticism of the go team.

Personally I love the generics! When it is a good idea to use them is also a tradeoff, of course.

[Daniel Smith @originalavalamp]

@the_sttts Yeah it is horrible to do this to the spec, but the error happened prior to templates and backwards compatibility is more important.

[Daniel Smith @originalavalamp]

@liggitt @ibuildthecloud @dims I wasn't going to mention names--there's more than one cook in that kitchen--but yes. I think apiserver internal code should be judged more on whether it does what it needs to than on being easy to reuse etc. It kind of froze half finished because k8s got too big to take risks.

[Daniel Smith @originalavalamp]

@ibuildthecloud @dims No. The initial package layout was due to me and I have no Java experience. (While I had more go experience than others on the team at that time, it was all idiosyncratic.) The people with Java experience got on board a bit later. I don't recall when the 'util' packages appeared.

[Daniel Smith @originalavalamp]

@the_sttts @kubernetesio 100% coincidence. We were looking at them in go struct order so we had no idea

[Daniel Smith @originalavalamp]

@KarlKFI @ibuildthecloud if an owner changed, it's not a no-op