Perhaps the weakest link in the US electrical system

probably because it Depends, If you dont know its safer not to. long answer (keep in mind i live in canada, im not a professional, this is just what i learned and trust, keep in mind above) - As long as no wire/bar exceeds its max Amp your safe no matter how many things are plugged in or how long of a daisy chain, the max amp is usually listed. - all devices should list the max amp they use, add up the amp's of all the devices connected to that wire and if its below your safe. - if your breaker is 15 amp, virtually all normal extensions/power bars are rated for at least 15 amps which means doesnt matter what you do the breaker should* flip before any damage is done - if breaker is above 15 amp most surge protectors have protection that will trigger if they exceed their max, most basic "splitters" and extension cords dont, eg if they dont have a switch or reset button they are pretty much guaranteed to not have this protection, be extra carful how much you load on those. some good rules of thumb to keep in mind, look for imprints or labels that list amps, smaller wires can handle less, damaged wires can handle less then they did before and shouldn't be used, if a wire or connector warms when its in use its overloaded reduce the load on it, especially if it warms quickly. here is a video that i liked that talks about it as well [this video]

This comes up now and again, somewhat akin to the Rust soundness hole issue. To be fair, it is a legitimate issue, and you could definitely cause it by accident, which is more than I can say about the Rust soundness hole(s?), which as far as I know are basically incomprehensible and about as likely to come across naturally as guessing someone's private key. That said in many years of using Go in production I don't think I've ever come across a situation where the exact requirements to cause this bug have occurred. Uber has talked a lot about bugs in Go code. This article is useful to understand some of the practical problems facing Go developers actually wind up being, particularly the table at the bottom summarizing how common each issue is. [link] They don't have a specific category that would cover this issue, because most of the time concurrent map or slice accesses are on the same slice and this needs you to exhibit a torn read. So why doesn't it come up more in practice? I dunno. Honestly beats me. I guess people are paranoid enough to avoid this particular pitfall most of the time, kind of like the Technology Connections theory on Americans and extension cords/powerstrips[1]. Re-assigning variables that are known to be used concurrently is obvious enough to be a problem and the language has atomics, channels, mutex locks so I think most people just don't wind up doing that in a concurrent context (or at least certainly not on purpose.) The race detector will definitely