seb

In Rust, how the borrow-checker shapes your API inputs and outputs .. The general design principle is to choose signatures that minimize ownership churn while keeping call sites clean and safe. Accepting input • Borrow when you only read: `fn parse(src: &str)` • Borrow mutably when you mutate in place: `fn fill(buf: &mut [u8])` • Own when you need to keep it: `fn spawn(task: String)` • Generic borrow (most ergonomic at call sites): `impl AsRef`, `impl Borrow` Returning output • Return references if tied to inputs: zero-cost, but lifetimes couple API to caller data. • Return owned values if independent: more flexible, slightly more allocation/copy. Trade‑off: returning `&'a T` forces the caller to keep `T` alive - returning `T` avoids lifetime coupling.

recently i started telling candidates right in the first interview that greptile offers no work-life-balance, typical workdays start at 9am and end at 11pm, often later, and we work saturdays, sometimes also sundays. i emphasize the environment is high stress, and there is no tolerance for poor work. it felt wrong to do this at first but i’m convinced now that the transparency is good, and i’d much rather people know this from the get go rather than find out on their first day. curious if other people do this and if there’s some obvious pitfall i’m missing.

dia is the exact opposite of how an ai product should be built. the ai should feel like magic to use and deeply integrated into every aspect of the product. dia’s ai feels like a cheap after thought, tacked on to the search and side bar because the vcs asked them to.