voxtech's comments

Why would it need to be faster than its peers to be impressive? That implies that a person can only be impressed by one thing in any given category.

1% of the sustained effort being spent on terminal emulators would be like a third of an engineer, so I have some great news for you.

He was the CTO, what do you mean he wasn't in any way involved?

attritioning out staff is one of the dumbest strategies imaginable- it's not a good job when the market isn't competitive either because your highest performers are STILL going to be the first go and you can't even replace them.

It never works but companies always try it and then HAVE to do a shady layoff just to rebalance their teams.

Stack switching isn't that much of the overhead. "ordinary" cgo overhead is <100ns now, has been for a few years, and is much closer to 30 than 80 on recent processors. Most of the overhead is a set of 4 CAS operations (incidentally this means that AMD has measurably lower cgo overhead because of something with its caching model I don't understand).

If cgo's only overhead was the "ordinary" overhead, most people wouldn't have an issue with it. It's downright zippy, in fact... as long as your syscall/C call takes less than 1us. If you stay under the 1us threshold, go will put the OS thread used for the syscall back where it found it and everything moves on.

The issue is that the OS thread was previously serving N goroutines that other parts of the program may be waiting on to move forward, and the OS thread is in a state where go can't pre-empt it and allow those other goroutines to move forward, and it has no idea how long it will be until it can move forward.

As a result, if a syscall/c call takes longer than 1us, go has no choice at this time but to resume a new thread, context switch all the old work onto that thread, and then suspend the syscall thread when it comes back. If you do this a lot, your performance will crater.

There's also separately a few issues around how go chooses to resume/suspend OS threads (for instance, if an os-locked goroutine does coooperative park for any reason to wait on another thread to do something, go will suspend the thread it was on, context switch to a different thread, then when the goroutine wakes up, it will realize its mistake, resume the thread it was on and context switch again).

This is all fixable stuff, but all the use cases that google cares about are working fine so it doesn't really get any attention.

More importantly, there is no threshold of usefulness where continuing the behavior is justified.

If the behavior is unimportant enough that drew should accept eliminating it, then its value does not justify the load.

If the behavior is important enough to justify the load, then eliminating it is no solution.

I'm more weirded out by the fact that you believe google is performing this DDOS for no actual benefit and are choosing to defend it anyway.

We shouldn't have to speculate as to why he was banned, as the CoC requires communication to him about why. If they're breaking CoC to get rid of the guy (and likely because the CoC prevented them from doing so in the past), it's hard to justify no matter the reason.

And to be frank, filippo's contribution to this thread places a clear reason why- drew was incredibly rude in the second link, but his arguments were not bad faith. He clearly meant everything he said, and I would even argue that he was right, although his method of engagement was unacceptable.

More importantly, the exchange was 3 years ago, and the more recent exchange showed him engaging exactly how I would expect a professional to. If the 3 year old exchange is the best filippo could find, it indicates that drew has changed his tactics for the better. So why the ban?

If the workaround didn't degrade service for Drew's go users, google would just implement it for all repositories.

This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.

It's an unusual situation because the document I think pretty badly misrepresents what happened right up until Peter LOST HIS ENTIRE MIND. In particular, Brendan Dube is a well-known stupid prick on the slack and he was being a stupid prick in this particular conversation. Peter's initial response was well-deserved but oh man did he lose it afterward.

Same here, toward the end of 2015. I would not have a serious high-paying job right now if it wasn't for triplebyte. I'm sad to hear the process hasn't scaled because I think that it'd help everyone out if it had.

Why not just offer junior engineers for free? If companies don't want to pay you for junior engineers, they're not going to suddenly start caring when you're giving them 10 instead of 1. If they're paying you for seniors just let them pay you for seniors.