In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out?

I know it’s a toy example, but one must consider all these things in a real system. Go does have good pathways for these concerns, but it’s also easy to do it wrong. I still have to manually reason about access to variables/struct fields from multiple go routines.

> This is a property called “equal delta mapping”

FWIW I’ve worked in computer networking for 20 years and have never heard it called this. This blog is the only source that comes up when I search for that exact term. I wonder where the author got it from.

This article used the word “laser” much more than I would have thought necessary. Couldn’t we accomplish the same thing with analyzing cctv video?

The code’s value is measured in its usefulness to control and extend the Facebook system. Without the system, the code is worthless. On the flip side, the system’s value is also tied to its ability to change… which is easier to do if the code is well organized, verified, and testable.

All systems break. Complex systems break in complex ways. Robots will definitely have bad days.

Undercut competition. Use borrowed money to sell rides under cost. Wait for all competitors to die. Jack up prices.

AFAIK they’re still living on borrowed money.

It reminds me of the airline deregulation of the 90s. New airlines would use borrowed money to sell seats at below cost to attract customers, driving established carriers out of business.

The funny thing is that this smells a lot like “the tragedy of the commons”. Everyone wants to use this amazing infrastructure for flying, but no one wants to pay for it. New firms undermine the stability of the system by charging less than cost in order to starve established competitors whose business model is focused on being profitable.

I disagree. Most engineers I work with like refactoring. It’s usually well defined work with clear metrics for success. It can also reduce daily pain if it makes delicate/messy code much easier to work with.

The problem with refactoring is that its only value is in improved execution of future projects. So it can be extremely valuable or completely useless. It depends on how likely the refactored things are to be worked on again.