Letting it get too cold could lead to plumbing damage if you parts of your house get below freezing. 15C is probably higher than I'd leave it if it were vacant, but you do want to leave the heat on and a decent buffer to account for temperature variations in other parts of the house.
I discussed the temperature with the guy who oversaw the construction and he told me that, given that the house is still pretty fresh and moist (it was finished in November '22), lower temperatures would mean a risk of mould developing. 15-16 is the sweet spot according to him.
My favorite part of all these "buy now pay later" services is going to buy some charging cables, a few bags of flour, or other small random stuff and being offered to split a $19 purchase into 4 equal payments.
It's always good to understand what the policy is on an offer like this, but most credit card intro rates are not like this - it is typically store charge accounts that offer "12 months same as cash" that accrue interest and add it if not repaid during the time offered.
Not defending their actions in this particular case, but yes, I think it is completely reasonable for a service like MailChimp to be concerned about unauthorized use of user accounts. If someone takes over a MailChimp account, it is almost certainly to send spam/fraud type stuff, which causes harm to MailChimp in various ways.
Compliance with those standards doesn't mean they aren't potentially impacted by that sort of thing, and doing what they can to detect and mitigate unauthorized user account usages is part of at least a few of them.
I am interested in this area too, but I don't know of any single place to follow it all. I have found that there isn't an avalanche of "new" stuff, but a lot of different ideas with different tradeoffs that change in relevance based on usage patterns, languages/runtimes, and hardware characteristics.
Besides the JVM resources linked by others, I found Richard Jones's "Garbage Collection Handbook" to be a decent introduction for background [1]. The Go team has written a bunch about their GC approach [2] - it is really interesting to see how it compares to the various options in the JVM and under which scenario you might prefer one or the other. And occasionally there are interesting articles on arxiv.
And then when a dependency of one of your dependencies is broken agains the latest version. I know some of this has been cleaned up, but it is one of the main reasons I no longer use Scala - I have a rule about how long I'm willing to spend on build issues vs actually writing code, and Scala was always on the wrong side of that.
re: Complexity - At least the signatures for the core collections have been cleaned up a fair amount. That said, the richness of the type system and the prevalence of operator overloading always made it feel like a language you could be really productive in once you knew the language and the current codebase really well, but was really hard to just read through unfamiliar code and know what is going on.
> And then when a dependency of one of your dependencies is broken agains the latest version
How is this any worse than Java? My most vexing dependency-hell issues have involved breaking API changes to Hamcrest matchers and Apache Http Client; more recently Jackson-databind. All of those are Java libraries, brought in via transitive dependencies, usually from Java libraries.
There was definitely a large and vocal part of the community that wanted that, but I think early on there was a lot of tension between Scala being "better Java" and "Haskell for the JVM", and that probably hindered a lot of adoption.
> Over exposed to US treasuries? I don't think anyone has put those words together before.
Only if your definition of risk is limited to default risk.
It looks like a lot of their holdings were in MBS and a lot of the treasuries were recently sold at losses (which necessitated raising capital, which appears to have set this whole thing off), but there is no reason this couldn't have happened if they only held treasuries anyway.
I don't this is an area of corporate law that has been super thoroughly tested? But I think the theory is -
Look, we had $X in our account on Wednesday and did a payroll run that was more than covered, but then our bank went under and the payments never got there. That's not our fault, nothing we can do about it!
But as time goes on and you're still employing people while having no bank account, you become more culpable for their unpaid wages after you find out you have no money.
The tricky thing here, I think, is that it still isn't very clear what is going to happen and it'd be silly to immediately fire a bunch of people because of it. There is a good chance some other bank acquires SVBs accounts and things are back to normal pretty quickly. If that doesn't happen, there is still a lot of money to go around, so you aren't losing 100% of what is in there.
I think there is a good argument that it is prudent and legally defensible to wait a day or two to figure out what is going on before you go nuts and shut the business down.
1:1 banking essentially guarantees long-term loss of principal for depositors, albeit slowly. The main "service" a bank would provide in that scenario is holding onto your money for you and instead of paying interest on it, charging you a few percent per year to hold onto it for you.
Also, in your model, where does money for loans come from? How are borrowing costs impacted by a major source of funds for loans going away?
Ironically, returns on bank savings accounts have been so low for so long that my present APR of like 1% is functionally the same as if they just held onto the money for me. That would probably do a great deal to explain why no one uses savings accounts anymore
