Upsert?

Maybe it's spite-driven development, but I'd love to hear about someone who, upon learning that LLMs are suggesting endpoints in their API that don't exist, implements them specifically to respond with a status code[0] of "421: Misdirected Request". Or, for something less snarky and more in keeping with the actual intent of the code, "501: Not Implemented". If the potentially-implied "but it might be, later" of 501 is untenable, I humbly propose this new code: "513: Your Coding Assistant Is Wrong"

[0]: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

If they keep predicting that, eventually they’ll be right!

(It’s hard to harvest more power from a star than a Dyson sphere is capable of)

Direct link to the chair:

https://rovagear.com/products/rova-chair

(Not an endorsement. Just if you’re curious.)

Phones today show in the status bar if the camera/microphone is active.

I think the term "software engineering" sometimes does more harm than good. Because we call it engineering, we tend to act like it's a rigid, well-defined discipline...like civil or mechanical engineering...where things have precise definitions and there's a right way to do everything. But in practice, software is full of gray areas. Take testing: people argue intensely about what counts as a unit test vs an integration test vs an E2E test, as if there's some pure Platonic definition out there. The same goes for debates about microservices vs. monoliths, service-oriented architecture, and so on. The energy behind these arguments often feels religious, not practical.

Over time, I've found that the only reliable way to reason about engineering decisions is to work backward from the business use case. What are we trying to accomplish? What's the time frame? What risks are worth taking now vs later? Everything else...patterns, paradigms, "best practices"...only make sense in that context. The rest is academic, and often divorced from reality tbh.

Also noticed that many strong opinions in engineering come from people trying to avoid pain they've experienced before. But the solution that saved them in one situation can easily become a liability in another. Patterns ossify into rules. That's why I try to keep my reasoning grounded in outcomes and context, not ideology. Most "best practices" are just local maxima..useful until they arent.

>You're imagining something which can't exist.

Excuse me, what is hard in taking this: https://doc.rust-lang.org/book/appendix-01-keywords.html

And translating those back and forth?

In fact, if it "can't exist", how can Rost be "fully compatible with English-Rust, so you can mix both at your convenience"?

And Rouille? https://github.com/bnjbvr/rouille

And Unirust? https://github.com/charyan/unirust

But how do you tell them that the emperor has no clothes when they drown out your voice?