mcronce

I don't. I avoid Go like the plague. My point was that you don't get to unilaterally decide for everybody whether fast compile times or runtime performance is more important.

No basis other than clear observation of reality, you mean?

Persistent storage tied to a specific member of the deployment is a StatefulSet feature. That's likely what they mean by "stable", although I really wish they were more clear about it

There's nothing stopping you from installing using rustup. There are also tons of projects that have much older MSRVs than simply "latest stable".

> Fast compiler times are more important than being the fastest at runtime.

For you, maybe.

How does building overcapacity help when those sources aren't producing at all?

Building overcapacity is required with storage. It doesn't help without storage.

This isn't really accurate. There's a reason that fossil fuel companies/executives "embrace" intermittent renewables while running decades-long smear campaigns to turn public opinion against nuclear.

Oh, I see. You are handwaving away the nonexistent storage tech required to stand up a power grid. Please stop.

The fact is that without inventing new storage tech, which might or might not be possible, the only options for powering the world are nuclear or burning more carbon.

Personally, I'd rather humans still have a viable habitat in a century.

Quantify "a bit" for me.

If you ignore the fact that wind and solar work when they want to, you're absolutely right.

This presupposes that economics are the most important thing.

That isn't really the case.

It doesn't matter how much money you have when the climate burns to the ground around you, while energy sources that work when they want to fail to provide for your needs.

I was going to say Facebook

I had the same experience. If you want to branch out, Tyrell Knifeworks - https://www.youtube.com/c/tyrellknifeworks - gave me a similar experience with knife forging/construction

Not really. It takes a sustained load over a long enough period of time to raise the temperature of the aluminum chassis to the point that it causes physical pain. If that's your use case, you have a point, but that's not most people's use cases, mine included.

Imagine unironically defending this behavior.

IT can lean on the vendor to fix their shitty software.

If the head of IT doesn't want to do that, the department is dysfunctionally managed and does not have my sympathy.

Beyond that, I don't really care what policy is. While I generally don't care about company nannyware - after all, it's your machine - the line is drawn when you are literally burning my body. If you want me to use the device, it can't cause me physical harm.

A few companies ago, our IT dept's nannyware had a bug on OSX that was causing it to peg a CPU core at random. So, in engineering, we obviously just found a way to disable it. The IT guys were not amused. "It is against IT policy to disable this software" - yeah, well, it's against my policy to let your stuff burn my legs; get the bug fixed and I'll turn it back on.

I've never had this experience with AirBnB - although I have had some crappy ones, but not nearly this bad.

I was just in the process of booking a car on Turo yesterday for the first time in a while, though, and did see a ton of listings where the owner says things like "go read these rules that are linked from my profile page; if you don't follow them to the letter I won't hesitate to cancel your booking last-minute"

Pretty offputting, honestly. If I could stomach driving automatics I'd just go to Enterprise.

Not really, no. You either need storage tech that doesn't exist and might or might not be possible, or you need to grossly overbuild intermittent sources everywhere and make megagrids, the likes of which the world has never seen.

Maybe those are possible. Maybe they aren't. We don't know. There is precisely one known working option.

Honestly, that last point seems like something that would make on-call extremely palatable. Essentially acknowledging "on-call sucks; in return, here's the latitude to work on whatever you happen to think is important/interesting"

> Which will come from renewables.

This is something solar/wind zealots often like to repeat, while hand-waving away the fact that those energy sources work when they want to, not when you want them to.

If you want a reliable, clean power grid, there's one option, and it's not solar and wind.

This is consistent with my experience. Semantic versioning is very very widely used in the Rust ecosystem, so you're not looking at breaking changes unless you select a different major version (or different minor version, for 0.x crates) - which you have to do manually, cargo will only automatically update dependencies to versions which semver specifies should be compatible.

For crates that don't follow semver (which I'm fairly certain I've encountered zero times) you can pin a specific exact version.

I was using a French press prior to switching to pourovers and while I don't care for it as much as I do a pourover, it is undeniably a very fast way to make a cup of coffee

I saw that episode and imitated with my Milwaukee cordless drill. It's very very good.

Honestly, as somebody who does pourovers that take like fifteen minutes between grinding the beans, heating the kettle, pouring, and finally drinking...sometimes I do yearn for just a Keurig-like fast-shitty-cup-of-coffee experience without all the plastic waste.

It reduces transmission.

You weren't unable to attend anything. You had an option to attend the event - get vaccinated. You chose to not attend the event. The only thing "keeping you" from it is you.

> long after covid is any sort threat whatsoever

People dying and people with - and still getting- long COVID would probably disagree with that statement.

If you've got a thread running one event loop, how could you signal to it to temporarily break out of that loop and run a different event loop for a while?

This assumes that people only use Rust for the performance. I don't think that's strictly true.

95% of what I write isn't performance-critical or even, really, performance-relevant. I still choose Rust for the vast majority of projects for ergonomic and correctness reasons.

If your function is fallible, your function is fallible - it's up to you to decide whether that means returning Result or panicking. If you want your function to be infallible, while itself calling a fallible function, you have to handle the error cases from your callees - you have `.unwrap_or_default()`, `.unwrap_or_else()`, `.unwrap_or()`, and simple `match` all in your toolbox to do this.