aaronbwebber
Joined 11 years ago
Joined 11 years ago
tfa appears to admit that people are actually _using_ the new Milwaukee flag. This seems like a pretty strong argument that the new flag actually is better than the old flag? It is kinda cool to have a very distinctive local flag, but if the practical upshot of that is that the flag isn't actually used anywhere except a single flagpole in front of city hall (if that), seems like the vexillology people kind of have a point?
Many applications do not require true durability and it is likely that many applications benefit from lazy fsync. Whether it should be the default is a lot more questionable though.
That seems like an important distinction, and makes the rest of the article (which focuses on educational accommodations) look mistaken.
it really takes about 5 seconds of thinking about this to realize why this "analysis" is stupid - he takes an INCREDIBLY expansive view of what counts as "pollution" from food production and then takes the narrowest possible view of what counts as "pollution" from driving a ICE car.
It's frankly embarrassing that econlib would even host this kind of crap which would get a failing grade in an undergraduate econ class.
https://go.dev/doc/articles/race_detector
Edit: at the _end_ of the post, they mention that this is the second of two blog posts talking about this, and in the first post they explain that they caught these by deploying the default race detector and why they haven't been running it as part of CI (tl;dr it's slower and more resource-expensive and they had a large backlog).
https://eng.uber.com/dynamic-data-race-detection-in-go-code/
> A newly minted goroutine is given a few kilobytes
a line later
> It is practical to create hundreds of thousands of goroutines in the same address space
So it's not practical to create 100s of Ks of goroutines - it's possible, sure, but because you incur GBs of memory overhead if you are actually creating that many goroutines means that for any practical problem you are going to want to stick to a few thousand goroutines. I can almost guarantee you that you have something better to do with those GBs of memory than store goroutine stacks.
Asking the scheduler to handle scheduling 100s of Ks of goroutines is also not a great idea in my experience either.