Some comments seem to be optimistic about the potential change from Apple. But once Apple relax webkit requirement from app store, it will mean all "do not track" cookie enforcement would be easily worked around.
The default can still be Safari, not "all" enforcement will be worked around. We simply can't trust Apple to do the right thing without supervision, though. As we've seen with the App Store, Apple uses these positions of de-facto authority to disempower the user and reinforce their own profit margins. We let them fly by the seat of their pants for too long, regulation is long overdue for this business (and app distribution sector as a whole).
If you want to opt-in to Apple's protective blanket, do so. It's not an excuse to weld over the safety hatch for the rest of us.
The default _browser_ will mostly be Safari. But the moment webkit requirement is relaxed, all in-app browsers for Facebook, TikTok, Youtube, Instagram, etc will be replaced with their own forks without any respect for "do not track". They will become the second most used browsers on iPhone, not Firefox or Chrome.
I think what the article is addressing is likely not what is being discussed in this thread. The article ("Unfortunately, I often see solutions abusing exceptions" followed by using exceptions to replace if statements) is very likely discussing poor understanding of the topic from student assignment rather than actual code in the industry. Such mistakes (abuse of exceptions in the article) often go away once students become actual professionals because these mistakes are more easily caught during code review than other types of common mistakes.
It's just that science is easy to verify for the people that know how. If you are actual expect of any other topics (thus can verify if their news is any good), you'll find the news for those topics is at best as bad as for science, if not much worse. News cannot be 100% faithful to the material it covers, and the more you understand about the topics, the more discrepancy you can see.
I'm not sure I understand your comment that science is 'easy to verify' - how would any of us verify that the LHC actually found the Higgs boson a few years ago? (10 year anniversary coming up on July 4th)
You're missing the "for the people that know how".
I agree with GP: Most news is bad, but people can really only tell when it bumps up against something they know. News on science just has a bonus where research gets published separate from the news, and so even people outside the field can compare the two and point out exactly where the news is wrong.
I don't believe this has anything to do with AI, it most likely is rule based (not the entire system, just inclusive warnings). People like to shit on AI, but AI wouldn't really make such ridiculous suggestions, only human can.
The suggestions look a lot like code linters in FAANG companies. People from the outside will be shocked at some of these "inclusive" linters if they take a look.
Both flow and typescript are great tools. Typescript has much better tooling and great IDE integration, using typescript is a no-brainer for new projects. Flow's soundness does shine though once your codebase (and your team) becomes very big, as any unsafe cast can be reliably treated as error. I use flow at work, and so far my experience is that unsafe cast in flow always indicates a bad design or actual bug.
Every time I read something about TempleOS, I was amazed by its concepts and Terry's dedication. I wonder if one day we could see something like "doom source code review" on TempleOS.
I really like watching the code reviews Terry has put on youtube. Watching him use his own creation to navigate, test and explain his own creation is very interesting.
I understand he has an interesting technique for putting together those code reviews, too: he uses a random number generator to randomly pick a piece of the code, then starts walking through whatever it chooses.
I really hate people advocating micro services/libraries because they just migrated and "everything got much better". No, everything got much better because the known/actual problem domain changed and system is re-adjusted accordingly. When you start with very little knowledge of the problem domain, any fine-grained architecture is premature optimization, and what you really want is to rapidly expand your understanding of the problem.
Projects can fail in many ways, not trying to understand the problem better and not trying to re-adjust after are typical pitfalls. Migrating from monolith to micros is just a natural transition between SOME stages, and it shouldn't happen until you hit those stages. You may hit those stages very early, or sometimes never.
Compared to facebook's barebone flux library, the only real advantage these frameworks provide is about server side rendering. But I'm worried this will become irrelevant once facebook Relay is out.
