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?
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.
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.
The alert fatigue is _very real_; I have a dexcom and consistently see it:
- mis-calibrate (first day's readings are garbage after new sensor insert)
- UI on the app will sometimes mis-render by 10-15 minutes. On several occasions I have been watching the graph while dosing, didn't see any change whatsoever after 30/45 minutes, and gave more insulin because of that information. 5 seconds later the screen changes and displays 15 minutes of BG going steeply down as I would expect, but now I have 2x the dose in me -_-
While I'm swimming in sensor readings the actual impact on my treatment quality has been close to nil, but it does make the people around me feel better. I feel as if my ability to sense my own levels has worsened because I default to trusting the graph over how I feel.
I cancelled my subscription shortly after they started getting rid of small-time films and started producing their own content; the two reasons were (1) I don't like businesses that can't cooperate with others and (2) their own content sucks and likely continues to suck to this day because their KPI is "how many people watched >1s of this?" and not "did we allow passionate, talented people to do work they are now proud of?".
This guy sounds like he's fishing for attention, the phrase "I didn't think I would have the courage to share..." is something 10-year-olds think up for attention. It drips vanity and a covered ego the size of the Hindenburg.
D is an excellent mix of good design decisions, metaprogramming (your macros can run arbitrary code at compile time, a la zig), and a nice standard library. They also have some of the best API-building libraries available, and the compiler has the ability to run source code almost as if it were interpreted and it caches binaries under /tmp/ to avoid work if the source is unchanged.