desolate_muffin

I don't write Go, but reading this, it feels like you don't actually need functional scoping at all. In Java, I would simply write:

try (SomeResource foo = SomeResource.open()) { method(foo); }

or

public void method() { try(...) { // all business logic wrapped in try-with-resources } }

To me it seems like lexical scoping can accomplish nearly everything functional scoping can, just without any surprising behavior.

It's not hard to imagine an alternative universe where Github is a steward of innovation for both git and the code review process; alas, this is not the world we live in.

I am not sure what you mean. Stateless RPCs, cache controls, client-side typing, tracing/observability, and bidirectional streaming are all things that strike me as very relevant to the modern web for all but the smallest of toy projects, let alone projects in serious engineering organizations.

> Author also seems to expect that the result from MCP tool usage will feed directly to an LLM

Isn't this exactly what MCP is for? Most tools I've come across are to feed context from other sources directly to the LLM. I believe this is the most common use-case for the protocol.

In addition to what others have complained about, another issue I haven't seen highlighted as much in the comments is the infuriating explosion of content length.

AI responses seem to have very low information density by default, so for me the irritation is threefold—it requires very little mental effort for the sender (i.e., I often read responses that don't feel sufficiently considered); it is often poorly validated by the sender; and it is disrespectful to the reader's time.

Like some of the other commenters, I am also not in a position to change this at work, but I am disheartened by how some of my fellow engineers have taken to putting up low effort PRs with errors, as well as unreasonably long design docs. My entire company seems to have bought into the whole "AI-first company" thing without actually validating if the outputs are worth the squeeze. Maybe sometimes they are, but I get a sense that the path of least resistance tends toward accepting lower quality code and communication.

This phenomenon really frustrates me on behalf of my peers. I'm not sure what the right answer is, but anecdotally I've observed many others struggle to get their first jobs in tech, while, meanwhile, I am mostly being assigned to interview people who require visa sponsorship. Most of my referrals for my low YOE peers are rejected before the recruiter call. I have observed this at both very-big tech and my current medium-sized tech company.

I have also observed that on my team, more than half of the people are either currently on immigrant visas or were previously on immigrant visas. Just to be absolutely clear—these people are great, and I don't fault them or hold any ill will for them having coming here to work.

At the same time, it seems that most hiring is done at the mid and senior level. If we only hire senior talent and rely on immigrant visa labor to fill these ranks, where exactly is each subsequent generation of seniors supposed to come from? I feel there should be some requirements in place to ensure that companies aren't perpetuating this shortage by hiring very few domestic workers at the entry level.