> but every time I price out a beefier box I feel like the ROI just isn’t there, especially for an industry that is moving so fast.

Same, esp. if you factor in the cost of renting. Even if you run 24/7 it's hard to see it paying off in half the time it will take to be obsolete

Agreed. They wouldn't have to use so much that they suffered the negative affects to use enough to get past their borderline irrational hangups

Putting the affects of marijuana abuse in the same category as meth or heroin is dishonest and dangerous. It destroyed their credibility.

I agree that short term memory loss being a side effect of heavy use is common knowledge to anyone who is or knows a heavy user.

But I think you shouldn't be so confident that smoking when young is a huge problem long term.

I would have been in the 'heavy user' category by the time I was 17, and I've had the odd experience of persistent short term memory loss (e.g., having multiple people tell me 'you just asked me that' with a bewildered look). I also quit smoking when I was 17, and haven't had any noticable symptoms since I was 20 (> 20 years ago). I doubt if anyone who knows me would say I'm not 'successful.'

Not recommending heavy use, to be sure. Just saying that it's not necessarily a permanent, long-term effect.

You write the 'add item' event regardless, and when building the 'cart' view you handle the limit.

add_item is not an event, rather a command/ request that is yet to be validated. item_added is the event = a fact that was 'allowed to happen' by the system.

Keeping commands in a persistent store is a matter of choice but not necessary. I've seen people doing command sourcing and calling it event sourcing.

Alternatively "invalid cart" could itself become an event.

Well, assume the non-overdraftable bank account example instead then, what do you do then?

Sounds like an easy way to run out of storage space

I wouldn't hold my breath. At my previous house, CenturyLink/quantum site said it was available. I called half a dozen times to get it installed, each time some contractor would show up and tell me it's not available. I was confused because they spent months very visibility installing it throughout the neighborhood. Talking to some of the contractors, it was interesting to hear stories about why it was available in some areas but not others just a few houses down.

Eventually, one of them did figure out how to get me connected.

Can you say what the issue was?

I didn't fully understand the details when they were explaining it to be, but iirc something was disconnected around the corner, and they couldn't just reconnect it because it wasn't the right hardware.

This played out over several months

Same here ($65 -> $75); I think it's an "equipment fee." I don't even use the router. My employer covers the cost so I haven't called to complain, but I suspect if you do you can return the router and lose the fee.

I keep the router they gave me in one of my garages. The only time I've ever connected it was when their service had a problem and they wanted to run remote diagnostics. The other 99.9999% of the time, I use an OpenWRT VM.

I would not have accepted the router if there were any strings attached, and they're welcome to take it back if they want to start charging me for it.

That's how it is in Vegas presently: CenturyLink has fiber service but it's scattered around unpredictability, and in areas where it's not available it may never be. Hopefully Google fiber (un)availability doesn't overlap too much, but I expect that it will.

You think the major complicating factor of rolling out e2ee was that they used react?

Given I was able to see the errors directly in the js console, yes. You used to be able to break everyone's state by putting an emoji in a URL.

I was hoping for stronger rationale than this. This is not a React-specific problem.

Of course it's not a "react problem". It's a skill issue created by the reality that React is incredibly difficult to scale in large projects.

If Meta cannot even handle React, what hope is there for the rest of us?

How speedy is the rust-language tooling itself these days? I remember wishing for a 'optimize nothing' or even 'just interpret' mode. Compile times noticably contributing to the feedback loop are a serious killjoy.

Compile times are still a bit much, but there are ways around it:

- The insanely long times are only for the initial build. Further builds are incremental and more tolerable.

- Compilation errors can be checked using 'cargo check'. It avoids the code generation step that's part of a build. I find myself doing it way more often than builds. So it's a time saver depending on how frequently you use it.

- You can extend the incremental build mentioned above using sccache [1]. At the minimum, it allows you to share the build cache between all your local projects. So it saves time if your projects or other builds share a lot of common libraries (that's very common in Rust, though). But sccache can go further by using online build caches (for example, using S3) that can be shared between hosts. Finally, sccache also supports distributed builds if you have a few machines sitting idle. (This is like distcc with extra features).

[1]: https://github.com/mozilla/sccache

There have been significant (if not earth shattering) improvements in the compiler itself. But for me at least, the bigger change has been from better hardware. I now have a processor (Apple M1 Pro) that's 10x (multi core) / 2x (single core) faster than the one I had when I first started programming using Rust (intel dual core processor in a 2015 MBP) and that seems to have translated almost perfectly into faster compile times.