Go is my default language for any non-client-side project. That said, I agree with all the criticisms, except for the one about unused variables/imports and the lack of warnings in the compiler. I'd also add one of my own - I'm an expert go programmer, but I still panic sometimes when dealing with error handling. It is still not as easy as it could be to produce useful error return values.
No, sorry but I don't think you understood the article. Readiness probes don't fix this. In fact, they could exacerbate the problem (although you obviously need them anyway). The problem is Kubernetes and the Load Balancer react to pod status changes at different times. (In fact, it's worse - different Kubernetes components also react to status changes at different times.) The load balancer is almost always too slow to react, so, it sends traffic to an instance that has already started shutting down.
Yes! I think this is a really under-reported issue. It's basically caused by kubernetes doing things without confirming everyone responded to prior status updates. It affects every ingress controller, and it also affects services of type "Load Balancer" and there isn't a real fix. Even if you add a timeout in the pre stop hook, that still might not handle it 100% of the time. IMO it is a design flaw in Kubernetes.
I agree spanner and cockroach are the future. Most people don't need a database that can scale that well, and spanner is too expensive to use unless you really truly need it. Also, google and cockroach have not done enough marketing. Look at all the marketing mongodb did - they actually managed to convince people to use a database that would regularly lose data.
Either they are too stupid to know you can't attack people and break into buildings, or they did it on purpose. Either way they can't be effective as CEO after that.
People were indeed arrested and fired for looting in protests earlier in 2020.
In case someone is curious, the optimization they describe is trivial to do in Kubernetes - just enter a resource request for cpu without adding a limit.
I'm not sure what you're trying to argue for here, but if we had allowed a huge initial spike, many hundreds of thousands would have died needlessly. We are still doing much better than that.
Yeah space really isn't the problem at all. It is nurses and doctors and oxygen. They have nurses - who are supposed to treat 2, maybe 3 at a time - treating 30 people at a time.
Prop 22 is a tremendous success for Uber and other companies. The courts and legislature in CA went out on a limb to force Uber and others to do the right thing, and prop 22 erased all their work.
If you don't live in California, you may not know - they added a $1.50 fee to every order, in addition to all the existing service fees and delivery fees, which often add up to 20-30% of the order. (Also by the way, uber and grubhub already artificially raise the prices of items on the menu and keep the difference, and restaurants can't do anything to stop it). They can blame it all on Prop 22 even though they spent millions to pass it.
Now obviously people are paying all these fees, so it appears that drivers are being paid a lot, so no need to tip. But most drivers don't even qualify for the money! We are paying money on orders that probably won't even go to our own driver.
Personally I've decided to stop using these food delivery apps. I can't stop using Uber, but I can pick up my own food. It is depressing that so many delivery drivers didn't understand what they were voting for and did nothing to stop this
You have to think about it like this: the average skill level of engineers at a large company will always move to the true average across all engineers outside the company. This means they have engineers that don't know what they're doing, and there's not much they can do to prevent it. The average "security" skill level is very very low, and even people who are good at it make huge mistakes constantly.
If you accept that, then it makes sense to spend time and money on preventing people who don't know what they're doing from hurting everyone else. It is therefore essential that mitigations like this are applied, even though if everyone did their job perfectly, they would not be necessary.
Hmm one thing that jumped out at me was the organizational mistake of having a very long automated "grace period". This is actually bad system architecture. Whenever you have a timeout for something that involves a major config change like this, the timeout must be short (like less than a week). Otherwise, it is very likely people will forget about it, and it will take a while for people to recognize and fix the problem. The alternative is to just use a calendar and have someone manually flip the switch when they see the reminder pop up. Over reliance on automated timeouts like this is indicative of a badly designed software ownership structure.
I have nothing directly against cloudflare but I think it would be better to try to support one of the smaller analytics companies if possible. They are the ones who made products that got big companies like cloudflare interested in the space.
I do the same thing with the timer app. I've only worked more than 8 hours when there was a tight deadline. I was surprised by how exhausted I felt on those days. On a normal productive day I get 6 hours, on a day where I feel shitty I get 4 hours. I was actually surprised by the amount of work I get done with only 4 hours of focus per day - no complaints from my boss or anyone else
> I had around $12K in savings. Enough to cover a year of expenses and a bit more. I stopped spending money on almost everything.
Yeah, that sucks. I'm sorry you had a bad experience.
I think one thing for the community to take away is you need to be in a good position financially before you can start a startup - unless you can get funding. Especially for indiehackers who don't usually take outside investment, $12k in savings is not enough. It is not normal to have to stop going out at all or to be pinching pennies. Not everyone can afford to start a startup. For some reason, this concept is almost never talked about in the startup community, but it's really important.