Readit NewsYou all need to grow thicker skin. If we're really engineers, we can't dance around criticism. Linus' comment was about the code; he never insulted the developer. If you attach your self worth to the code you write that's your problem.
What would you have him do? Sugarcoat it? "Uh actually sweetie please rework this function it's not quite there".
It's a PR; honest, unbiased feedback on the code (and optionally how to improve it) is the only thing that matters. If the code is garbage then the reviewer needs to say so.
Software engineering is a collaborative process, not an adversarial one.
I couldn't seem to get any message through without tool calling instructions in the payload. What you're describing sounds exactly like what I attempted.
I tried something like over 6 different variations of model configs with restarts of Zed in-between. The documentation and what Zed tries to configure are different as well. The fields don't match up with the built in type checking. I tried "openai" with the endpoint configured, "openai_compatible", and even "openrouter" hoping the REST signatures would be match well enough. Each configured with various fields to turn tool calling off and every single request that hit the REST server had tool calling.
"New text thread" should also have no tools I believe.
Good luck finding a project of any complexity that manages to adhere to that kind of design sensibility religiously.
(I think the only language I've ever used that provided top-level support for recognizing that complexity was SML/NJ, and it's been so long that I don't remember exactly how it was done... Modules could take parameters so at the top level you could pass to each module what submodule it would be using, and only then could the module emit types originating from the submodule because the passing-in "app code" had visibility on the submodule to comprehend those types. It was... Exactly as un-ergonomic as you think. A real nightmare. "Turn your brain around backwards" kind of software architecting.)
What you're describing with SML functors is essentially dependency injection I think; it's a good thing to have in the toolbox but not a universal solution either. (I do like functors for dependency injection, much more than the inscrutable goo it tends to be in OOP languages anyways)
It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.
And how will this look like, if your app doesn't have library C mentioned in its dependencies, only libraries A and B? You are prohibited from answering "well, just specify all the transitive dependencies manually" because it's precisely what a lockfile is/does.
When I, the owner of an application, choose a library (libuseful 2.1.1), I think it's fine that the library author uses other libraries (libinsecure 0.2.0).
But in 3 months, libinsecure is discovered (surprise!) to be insecure. So they release libinsecure 0.2.1, because they're good at semver. The libuseful library authors, meanwhile, are on vacation because it's August.
I would like to update. Turns out libinsecure's vulnerability is kind of a big deal. And with fully hardcoded dependencies, I cannot, without some horrible annoying work like forking/building/repackaging libuseful. I'd much rather libuseful depend on libinsecure 0.2.*, even if libinsecure isn't terribly good at semver.
I would love software to be deterministically built. But as long as we have security bugs, the current state is a reasonable compromise.
I think the better model is that your package manager let you do exactly what you want -- override libuseful's dependency on libinsecure when building your app.