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.

https://en.wikipedia.org/wiki/Crescent_Dunes_Solar_Energy_Pr...

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.

So don't just rush a fix out. Think about what the effects of a configuration change like this might be, and whether you are just making more problems for yourself down the line trying to fix something quickly.

> Mind that the workload was selected to be a good match for InfiniCache properties (large objects with infrequent access).

> The hourly cost increases monotonically with the access rate, and eventually overshoots ElastiCache when the access rate exceeds 312 K requests per hour (86 requests per second).

So this is not a replacement for the most common use cases for Elasticache. It is interesting as a cache in front of S3, but if you want a cache in front of S3...just use Cloudfront?

Honestly if I was AWS I would be ecstatic if people used this, AWS probably breaks even or maybe loses a little bit on optimal usage of this, and makes an absolute killing if someone using this has a traffic spike and ends up hitting their lambda millions of times.

You can say all kinds of dumb shit and sign your name to stupid letters and other people get to call for you to be fired, and maybe you will be! Even after that, you can continue saying dumb shit and signing your name to stupid letters, and I can go write buggy Perl 4 code, and nobody can stop us! Your dumb letters might not get published in national magazines and I probably won't get paid much for my code but in neither case is this a violation of our free speech rights.

I don't think talking about poverty in modern societies in terms of economic sectors instead of trying to address it at a societal level is particularly useful. The point of the article should not be "let's all pay more for food" it should be "give everyone a UBI and if that means food costs more because you have to pay people more to work as cooks or strawberry pickers, that's a _good thing_.