I think it's not out of bounds to expect a company to go a little further to compensate for an issue. A prorated 1 hour refund doesn't reflect the reality that maybe that hour was more important to the customer because it was their only free time in the week. A free week is way too much but a free day sounds appropriate.
If there is a hole in the street and you fall down it, you wouldn't expect a refund just for the 1 second it would have taken you to drive over that hole.
Instead you should be compensated for your losses - the time and money it took you to repair that tyre.
Same with a web service. If I pay for 24 * 7 service and it's not working when I go to use it, I want compensation for my time and effort resolving the matter.
For some that'll be small - eg. Searching Google instead, taking 30 seconds. For others it'll be a big headache.
But downtime of 1 hour is almost certainly more costly for the consumer than 1/30/24 * subscription price.
Yeah, no, that's not how any of this works. This is the definition of inflated self importance!
Your contract doesn't have an SLA. If you are important enough, you can certainly negotiate one - and it will be far more expensive than your prosumer subscription.
And even then you will not get a 1:168 or 1:720 SLA like you are expecting - that's simply ludicrous and totally out of touch with every reality. Even if you were a lucrative enterprise customer (which you are not) they'd tell you to get lost.
> If there is a hole in the street and you fall down it, you wouldn't expect a refund just for the 1 second
Actually, you wouldn't get a refund at all unless you suffer damage or injury, which is an high bar to prove in court and a totally separate ball game.
You do see that ratio in, for example, business Internet service. You’ll get a month’s credit immediately upon asking if they can also see the brief outage. Even typically awful Comcast was good about this. However, as you note, in exchange, you’ve probably signed a two or three year agreement with them and you’d owe the balance if you canceled early.
Yeah I never get the "we knew about it internally" excuse. I can understand if another reporter got to it on the same day and they were in the process of mitigating, but even then they should have to prove it somehow.
I'm sure someone will tell me why I'm wrong but it feels like they're just dodging payouts. Reduces trust and motivation to report it.
I don't support this idea of rewriting everything in Rust but the answer to your question should be fairly obvious. Rust that compiles will generally be stable assuming you don't do a bunch of unwraps and panics. C that compiles can seem fine until it isn't.
LLMs still aren't as good at detecting C memory management issues as an experienced developer. With Rust, that doesn't matter as much because generally the compiler will tell the LLM when it's wrong.
But this is Rust, not safe Rust, right? So, you still have a lot of ways to shoot yourself in the foot.
Of course, the C -> unsafe Rust -> safe Rust is more likely to happen than just going straight to (mostly) safe Rust (I doubt a 100% safe dbms would make sense).
This is all well and good in theory, but the number of times I've seen tests that don't actually test what they say they're testing is hard to count. Yes even when you encourage the developers to ensure the test fails first and do TDD. Tests help you ship with confidence but there's usually at least a few that are just passing by pure luck.
So no, I wouldn't judge a rewrite as being equal just because it passes the tests. That said, I don't think that means you shouldn't do it. You just have to be pragmatic about it.
Except all major social media sites are also corporations with their own interests. I'd rather the business model of traditional media that rides on journalistic reputation to a recommendation feed where the only job of it is to keep you on the site, especially when said feed can easily be manipulated.
No media organisation is perfect but your description of social media as some nirvana of decentralised truth is very questionable.
For what it's worth, this is commonplace in Australia too. I feel like you're describing a general safe country thing. I've lived in Japan so I know it's probably one of the safest places in the world, but I feel like what this thread describes is more US/Canada/some Euro countries being particularly dangerous, and not Japan being uniquely safe.
Canada is not particularly dangerous, but it has a horrible case of being drowned out by American culture (which strongly influences Canadians' subjective perceptions of their environs), and having the same kind of problematic urban planning as the United States.
I think it's more high-trust than high-safety. Most American cities (and certainly suburbs) are quite safe, and have only been getting safer over the past decades.
And yet we are constantly bombarded with fearmongering around children getting kidnapped on every street corner, every hour of the day.
I'll absolutely agree that a place like Tokyo is safer for a child on their own than NYC or SF, but the gap isn't as wide as the mainstream media would seem to suggest.
I think the main reason more time might be spent thinking is because there's relatively less training data on Haskell out in the wild, meaning an agent may have to check back and forth with static analysis to figure out what's valid.
Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.
Plenty of valid reasons to pick C, memory safety isn't a reason to trade off all other possible benefits. One big reason is portability, you can't compile Rust for example for certain targets.
reply