agent281

I'm in California and it seems consistent across the large grocery store chains to me.

I've seen that in American grocery stores as well. I think it's pretty standard. The main issue is that you constantly have to be alert and remember prices across trips.

I agree, but it would be a total quagmire if they allowed it to extend to digital services and other non-traditional uses of the term. Seems like it would have to relate to buying typical consumer commodity goods only or things would get weird.

I think it means that you need to keep the size the same and increase the price or keep the price per unit the same and decrease the size. I don't think digital services are considered to have shrinkflation.

Yes.

I'm going to add: in a place where they have the bandwidth to be honest and intelligent. Sometimes good people are in bad situations. It's important to recognize this.

> Coroutines are one of those terms that used to have a really price academic definition and has gotten a lot looser over the years. Python generators don't conform to the academic definition, but casually calling them coroutines is pretty popular now.

Could you elaborate on how Python's implementation doesn't meet the precise definition?

That's basically the plot of the Forever War. When you drop out of hyper drive (or whatever they called it) you never know if you are going to be battling a ship from your future or your past. The very society that you fight for is completely alien. It's incredibly alienating.

The big issue is that there are many land use regulations so you by and large can't use it as you see fit. Parking minimums are a good example of this.

At my last job, my manager was being flown in every week. He was in the office for three days a week and stayed at a hotel. His kids were apparently furious. The company was really committed to being in the office, but kept hiring people from different cities. It felt very destructive.

TBH, I don't really get the whole "insulting to good candidates" idea.* People who have been in industry long enough should understand that this is pretty common. If they get insulted, that's probably bad signal since they are taking it personally.

On the other hand, if the person is annoyed or frustrated by the idea I don't blame them.

* Caveat for people with high levels of experience going into more senior job titles.

Just ask ChatGPT. I'm sure we'll get exactly what OP was thinking.

It's definitely not a ghost town. It's just not a treadmill. It's hard to have a conversation on hacker news because (1) articles cycle through quickly and (2) you don't get reply notifications. Lobsters is a bit more human scale IMO.

IANA automotive engineer either. I'll quote national bureau of economic research:

> The probability of a fatality, conditional on a collision, is 0.19 percent -- or about one in five hundred. The authors find that being hit by a 1,000-pound heavier vehicle results in a 47 percent increase in the baseline probability of being killed in the accident...

https://www.nber.org/digest/nov11/vehicle-weight-and-automot....

At least part of what keeps people from switching to more eco-friendly transportation is the protection arms race: people buy bigger cars because they are safer for their occupants. This leads to more injuries because bigger cars do more damage. Which means people are more concerned about injuries and buy bigger cars.

This is one area where I am concerned about the impacts of electric vehicles. They weigh a lot more than ICE cars and might cause more significant injuries for pedestrians. There probably ought to be some sort of tax or fee on vehicles that scales by weight. However, that would favor ICE vehicles over EVs so it may not be popular among the people who might otherwise be interested in such things.

I disagree. Using an n^2 algorithm will exaggerate the difference between the two data types at higher values of n. Using a linear algorithm would give a more consistent perspective on the relative performance of the two data types.

This is what I like about SQL databases. They frequently have tables that you can query to find system information. This makes it easy to explore the system within the system.

The proc filesystem on Linux is philosophically similar. It allows you to understand processes by working with files.

That's only fair: I stole it from Anna Karenina. :]

https://en.m.wikipedia.org/wiki/Anna_Karenina_principle#:~:t....

Yeah, it's hard to say with any certainty. I agree that the far end is the curve probably looks nothing like the "neighborhood" a couple percent away, relatively speaking.

I also agree that the variety of data plays a big part in its complexity. If you have a few petabytes of data, but it's really only a handful of tables you can real hone in on the relationships. If it's a wide array of sources with many tables between them then you have some nasty problems like entity resolution.

All happy data sets are alike; each unhappy data set is unhappy in its own way.

I agree. Really seasoned data people are not common enough. Small companies need to buy services to lighten the load.

We both seem have a sense of the size of companies at different percentiles. At what percentile would you put your company with petabytes of data?

Hmm, I suppose it's a bit challenging to say. I initially thought that it wasn't for the 80% smallest companies and petabytes of data is probably puts you in the top 20%. (Most businesses are small businesses after all.)

However, I now realize that th biggest companies probably should manage their own data. If you're Google why would you use Snowflake?

So I don't know if you are the target audience for this blog post. It's pretty ambiguous.

If you have petabytes of data, I don't think this article is talking about your use case.

rsc also talked about the performance of channels vs coroutines in his blog post. If memory serves, it was 10x reduction in looping overhead.

https://research.swtch.com/coro

It seems like a different kind of boilerplate: instead the functions need to take a yield so you are threading the function through you program. I don't know if it's better to expect a return type or to force a function argument. I lean towards the former, but that might be because of familiarity.

I found the Slack channel to be pretty responsive and friendly. Still, I was a bit bummed because I kept running into issues. Some documentation links were broken and I tried to fix them, but I couldn't get the project to build on Debian. I tried safe stack and had the wrong version of .NET. Once I got the right one, I had issues running the project (turned out the path did not support the "#" character). A lot of the documentation assumed you knew the .NET ecosystem, but I was coming from python. It seemed like I kept hitting sharp edges.

I'm still curious about F#. It has a lot of neat looking features (units of measure, computation expressions, active patterns) and has some of the easiest to read code I've seen. I just don't know if my experience was representative or if it was abnormal. :/

I tried using the safe stack, but it seemed like it wasn't up to date with the latest version of .NET. Is that normal? Or did I hit a weird edge case in the ecosystem? (Or was it a case of PEBKAC?)

Pydantic was a pure python library and was rewritten in Rust recently. To be fair, I have seen some critiques of this rewrite. Specifically saying that the validation model could have been much faster in Python and switching languages papers over the deficiencies. I'm not in a good place to judge if this is true or not.

Literally feel waves of nostalgia looking at that layout. It's perfect!

When the temperature rises the air can hold more water. That leads to two issues: (1) rain is less likely to occur because the air is retaining more moisture and (2) when it does occur there is more rain. So you get less frequent rain that is more intense.

A lot of the bay area is due to old chip manufacturing plants. I want to say it has one of the largest concentrations of Superfund sites in the US, but don't quote me on that.

Edit: Don't quote me, quote the Atlantic.

https://www.theatlantic.com/technology/archive/2019/09/silic...