A large part of that failure rate is in phase 3. Your comparison with prototypes would be more like drug development before even phase 1. Phase 3 is enormously expensive, much more than the earlier parts. And what's even worse, you don't get to learn all that much from failures in drug development in many cases. You can't just fix the problem and try again, you essentially have to try a completely new molecule.
They did animal experiments first. But according to the article they didn't really look at the serious side effects observed in monkeys, or ignored them. But animal experiments can only provide warning signs here, they can't tell you what will really happen in a human.
There's so many ethical problems with the events as described in the article. The worst to me seems to be that the researchers/doctors seem to have downplayed the risks here. Which for a never before tried gene therapy that is meant to work inside the brain are absolutely enormous. The ethical issues around the money seem minor in comparison with that and the fact that they seem to have ignored similar side effects in the monkey experiments.
It's more of a problem with triggers. But in the end you're switching languages at that point, and devs that have no problem reading your backend language will not necessarily be good at reading stored procedures. Of course depends on how complex you make them.
And of course devs read the content of functions they call. Unless it's a well written library used by many different people, odds are the function isn't documented well enough and has quirks that force you to understand in more detail how it works. This is not external library code, it's still part of your application.
You do not need stored procedures or functions to prevent SQL injection. Any Postgres client library from the last decade or two supports parametrized queries, and that's enough. Odds are, most people will use an ORM anyway, which also avoids SQL injection.
In most situations I'd try to avoid using stored procedures. Unless you're all in on them, the effect will be that it hides some logic from the developers since it is not in the main part of the codebase.
The first thing a malicious AI worm would probably do is compromise enough developer machines and other servers to commandeer all the AI hardware it needs. So I think a purely digital AI attack would not need this.
Now, once the AI can carry all the compute it might need, I'd really worry when it doesn't only carry compute but also more explosive ordinance.
They're the first, I strongly doubt they'll be the last to adjust prices that much. The big cloud providers might have enough margins to eat the cost increases, especially since bare VMs are only a small part of their offer. But I don't see how the smaller, more VM-focused providers will be able to absorb the high hardware prices.
I don't know enough about this specific party, but a quick look at the Wikipedia page about them shows this quote, which to me does seem to suggest that the label is defensible:
> In a podcast segment about immigration and deportations Allard stated his opinion and said that "They will also be forced to leave, even if they are born in Sweden, because they have no natural connection to Sweden. They are not Swedish."
There's a huge difference between enforcing reasonable immigration laws and what some right-wing parties are proposing. I don't know enough about this specific party, but you'll find similar ones in other countries. And remigration is in the end about deporting even legal and well integrated immigrants.
The vast majority of duplicate closures use already answered questions as duplicates. So ideally that question should have answers that apply to the new question as well. In my observation this is usually the case, though the answer might be more generic.
I have also seen bad duplicate closures that weren't actually exact duplicates. But people talk like this is the only kind of duplicate closure that actually happens. I've no idea if the rate of bad duplicates is so much higher than I observed, or if people are missing that their question is actually answered in the duplicate.
Yes, you can. I am using that in production right now. An ASP.NET Core application as a self-contained single-file binary, without AOT.
.NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already.
See the documention here for the PublishSingleFile and SelfContained options:
AOT is entirely independent of single file binaries. And self-contained binaries that run without the framework installed are again a separate concept. There are some dependencies between these, but they are not the same thing.
AOT is not all that useful yet for many applications as important libraries still don't support it. So more something for things like CLI tools with a small scope.
It's not quite the same as with Go, the binaries get large if you can't trim them. But creating single-file self-contained executables is very much usable and works well otherwise.
Assume you fetch a single customer entity with their 100 order entities as includes. With single query this will join both tables and produce 100 rows that contain the order data but also each one contains the customer data redundantly. Now Imagine you had two includes there, that will multiply the number of rows again.
AsSingleQuery is as dangerous as this makes it sound. This works surprisingly well if you know that the number of included entities is low, but only then.
You can get much better queries here if you write a Select() and let EF Core translate that into SQL. That will probably do roughly want you are imagining here, usually with subqueries fetching the data from related entities.
I'd consider keeping the other personal data to be still easily justifiable, as you might want to support various account recovery options. And the odds that a user forgot their password only increases for old accounts.
Those articles don't require deletion in this case, in my non-lawyer opinion. There is still a purpose to keeping the user's personal information here. Sony needs that information to be able to grant the user access to the content they bought.
There's a difference here between an account that hasn't been used and doesn't hold anything of value and an account like this that holds items that were bought.