arch-ninja

Agreed. I LOVE Kagi as a search engine - so long as it answers queries in under 2s with no ads, I'm a very happy customer. I don't mind if they flirt with LLMs, but if the LLM work detracts from the search work they will lose me as a paying customer. If the LLM work slows down search results I also lose the only thing I pay for - search result response time and correctness.

The best approach would be to treat "High Performance" as a system-controlled attribute like "Can Read Location Data"; the app can make a request for a performance profile it's designed against, the user gets final say-so, the OS records the user's decision and re-uses it for future launches.

This gives best of both worlds; users who need performance pick it, users who don't need/don't understand get to be kept safe by Apple's scheduler. Apps get back the state, so they can render a different icon or something to indicate "Hey we'll do our best but your hardware may not max out because scheduling wasn't built for this task"

I love the idea! It combines social-network capabilities with in-person hangouts. Let me know if you need a C++/Rust/Zig developer for backend work. The required infrastructure sounds simple to build if you outsource payment processing. The most complex component will be a reputation system.

Guarantees about those things are impossible to add after a language/community abandons them, and you can Arc::<RWLock<T>> your way to writing Java pretty fast. I hold that keeping the strongest-possible abstractions is the best decision, even if that means your average developer needs to learn borrow checking. I've started a career writing Java, spent a year with Rust, and when I came back to Java my data structures were 5x as useful. I could spit out features _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it would have taken a week.

Yes there is a skill gradient, but everyone who doesn't climb that hill is a fool and a weaker team member for it in my opinion.

6 months if you're a college-sophmore-level student doing it part-time (my own experience + numbers), I'd estimate 3-4 weeks if you were spending more than 3hrs/day on it and knew 2 other languages.

Hasn't the solution to this problem always been easy? Just encrypt before you type it into imessages; this applies to _all_ untrusted communication channels. Don't tell me base64-encoding/decoding is what's stopping you from having perfect security?

I say 50% of the Internet is Duplicate. (N=2)

The leadership that makes up media won't be paid more if they cared more, therefore the organization they create won't ever care more.

Brent is the engineer building all the real tech that a company in the Phoenix Project is building, and when the MC (a manager, Bill I believe) realizes this he re-directs resources so Brent can do his job without interruptions, ultimately saving the company. Excellent read, it's the first book managers are told to read when they use SCRUM/AGILE incorrectly.

Agreed, my experience says the same. Good compromises will win every time, and most times the communication about 2 different ways to build the same thing will end up producing a hybrid that's better than both ideas alone.

Agreed

Would a "tax on bad decisions made by company & company's tools" be appropriate in the 21st century? I don't think you can sue an algorithm these days, but having the legal step to say that "whatever a company's tool decides, the company has also (legally) decided" would help solve many of these problems. You'd have to run these by legal before shipping.

Hmm hadn't thought of that. Did google have the same quantitative issues when they changes names or did that come a few years after? It could just be they timed their jump well.

The quantitative reasons alone would have been responsible for a small slouch, but everyone would think "Oh it's Facebook they'll get back in the game soon, better buy now". The renaming leaks information that leadership is scared and desperate, which makes those quantitative reasons more fatal because there isn't a (reasonable) recovery plan.