I thoroughly agree, you should always have CI tools to ensure it builds, passes tests, and meets whatever formatting and/or linting standards the team sets. I was specifically responding to "Rust makes it harder for a ‘contributor’ to sneak in LLM-generated crap". If I get a contribution from an untrusted party, I will start with the assumption that it's utter garbage, buggy, broken, and malicious and review it until I'm convinced it's not. Not because I assume the dev is bad but because it's safer to assume the code is garbage. If I get a contribution from a trusted party (e.g. a member of the dev team/employee/whatever) I will review the code carefully though not with as much paranoia. I don't particularly care if my teammates are using LLMs, but if they're submitting code they don't understand that's a great way to get ejected from the "trusted contributors" group, and if they're an employee it's a good way to get fired if they keep doing it after being warned not to.

That does sound unpleasant and I can understand why you prefer Windows. Personally, I rarely have problems with Linux that aren't self inflicted and IMO Windows is an absolute garbage fire of an OS so there's no way I'd ever daily drive it.

I have not and will not ever use AI generated code that I don’t thoroughly understand. If you properly understand the code you’re committing there shouldn’t be any damage. And beyond AI you should never commit code that you don’t properly understand unless it’s a throw away project.

True, but if you read the article the point is clearly not about source code vs non-source configuration. There's an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, "Don't make users merge changes."

Programming languages are tools. I couldn't care less about learning a new tool just for the sake of learning. My interest in learning tools is exclusively practical - if they help me do my work better.

I find functional languages interesting, but that's because I find the underlying theory interesting and worth learning for its own sake, not because I actually care about the specific language it's written in. Even then these days I'd rather learn about woodworking (which is currently my main hobby) than a programming paradigm I'm probably never going to use.

To me this is an argument for why Go should not add type inference to function/method declarations. Go is like Rust (I guess, I haven't used Rust) - type inference works for declaring a variable (or const) and generic type parameters but not for type declarations, methods, functions, etc. I was in the "more inference is always better" camp but now I'm thinking Go has the perfect level of inference. Except for function literals/lambdas. I really want go to infer the argument and return types when I'm passing a function literal/lambda to a function.

I’d rather spend my free time doing something I enjoy

Why? I see no reason to go through the hassle of learning yet another language when Go serves my purposes perfectly and I'm happy with it.

Why? I see no reason to go through the hassle of learning yet another language when Go serves my purposes perfectly and I'm happy with it.

I’m a cishet white dude so I experience effectively zero discrimination directed at me, but I am on the spectrum.

I guess basically everyone I regularly interact with either is also on the spectrum or has intense interests regardless, or is used to people like that. Though TBF I have learned to not get intense if I’m in public talking to random strangers. But if someone asks me a question like, “how do computers work”, I will answer at great length.

VSCode has tons of features that save a lot of time. Unless Zed manages to get close to feature parity, I don’t see how it can complete from a productivity point of view. VSCode’s UI performance isn’t stellar but it’s not nearly bad enough to counteract the productivity boost I get from its features.

I use various strategies depending on what seems appropriate, including the two you mention. I've never felt the lack of DI.