undefined | Better HN

0 points9rx1mo ago0 comments

It would be helpful for you to share a link to the Github issue you created. If the TLA+ spec you no doubt put a lot of time into creating is contained there, that would be additionally amazing, but more relevant will be the responses from the maintainers so that we're not stuck with one side of the story.

Of course, expecting you to provide the link would be incredibly onerous. We can look it up ourselves just as easy as you can. Well, in theory we can. The only trouble is that I cannot find the issue you are talking about. I cannot find any issues in the Go issue tracker from your account.

So, in the interest of good faith, perhaps you can help us out this one time and point us in the right direction?

0 comments

withinboredom1mo ago

I’m not interested in contributing to go. I tried once, was basically ignored. I have contributed to issues there where it has impacted projects I’ve worked on. But even then, it didn’t feel collaborative; mostly felt like dealing with a tech support team instead of other developers.

That being said, I love studying go and learning how to use it to the best of my ability because I work on sub-ųs networking in go.

When I get home, I’ll dig it up. But if you think it’s a fair scheduler, I invite you to just think about it on a whiteboard for a few minutes. It’s nowhere near fair and should be self-evident from first principles alone.

withinboredom1mo ago

Here’s a much better write up than I’m willing to do: https://www.cockroachlabs.com/blog/rubbing-control-theory/

There are also multiple issues about this on GitHub.

And an open issue that is basically been ignored. golang/go#51071

Like I said. Go won’t fix this because they’ve optimized for throughput at the expense of everything else, which means higher tail latencies. They’d have to give up throughput for lower latency.

9rxOP1mo ago

> And an open issue that is basically been ignored. golang/go#51071

It doesn't look ignored to me. It explains that the test coverage is currently poor, so they are in a terrible position of not being able to make changes until that is rectified.

The first step is to improve the test coverage. Are you volunteering? AI isn't at a point where it is going to magically do it on its own, so it is going to take a willing human hand. You do certainly appear to be the perfect candidate, both having the technical understanding and the need for it.

withinboredom1mo ago

Heh. I've had my fair share of mailing list drama. This is political AND technical. Someone saying "let’s cut throughput" is going to get shot down fast, no matter the technical merit. If someone with the political clout were to be willing to champion the work and guide the discussion appropriately while someone like me does the work, that's different. That's at least how things like this are done in other communities, unless go is different.

1 more reply

j / k navigate · click thread line to collapse

0 comments

withinboredom1mo ago

That being said, I love studying go and learning how to use it to the best of my ability because I work on sub-ųs networking in go.

withinboredom1mo ago

Here’s a much better write up than I’m willing to do: https://www.cockroachlabs.com/blog/rubbing-control-theory/

There are also multiple issues about this on GitHub.

And an open issue that is basically been ignored. golang/go#51071

9rxOP1mo ago

> And an open issue that is basically been ignored. golang/go#51071

It doesn't look ignored to me. It explains that the test coverage is currently poor, so they are in a terrible position of not being able to make changes until that is rectified.

withinboredom1mo ago

1 more reply

j / k navigate · click thread line to collapse