Pretty childish. People have no trouble looking past it when they care about actually shipping reliable software that properly handles all code paths. Including error paths that are ignored in so many codebases.
That comment is a good reminder that a good chunk of people commenting on HN are completely out of touch with the real world, the actual popular ecosystems out there, and what companies actually do and use nowadays to ship.
You are unfortunately right. I am a bit relieved because it seem generics don't seem that over-used in the community. But still, the language lost a lot with this change that felt super-forced and unnecessary. Biggest downside of the language by far.
That's funny because that's factually untrue. Go's early popularity and professional adoption were largely driven by its perceived productivity boost linked in part to the small surface area of its spec, long before this subpar generic implementation was forced into it.
That's actually very popular with pretty much anyone who's dealt with errors happening in programs... which I would assume is most devs after some time.
Right.
On a related note: "MCP is invisible to the LLM, or should be, under normal use".
I am not convinced there are any downsides for the harness to explicitly feed MCP keywords into the LLM. It seem explicitly doing it has many advantages. For example, it allows the user to ask to interact with a resource through "the configured MCP" rather than directly through some local cli or HTTP endpoints; which can steer the LLM towards the proper actions. Otherwise, the model could in-theory be "clueless" with such a request.
Not sure I understand what you mean. MCP servers and methods available do have to be visible to the model in some way so that it can spit out tool calls instructions to be executed by the orchestration layer around it.
But you probably meant something else?
While that is true, the overarching point is that it fundamentally still is, just a story.
You're just describing real world consequences, precisely because humans/societies believe in that story and enforce it.
> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation
This has always surprised me as this always comes up in MCP discussions.
To me, it just seem like a matter of updating the protocol to not have that context hungry behaviour. Doesn't seem like an insurmountable problem technically.
Glad you say it has already been addressed. Was the protocol itself updated to reflect that? Or are you just referring to off-spec implementations?
That’s exactly what it is in essence.
The MCP protocol simply doesn’t have any mechanism specifications (yet) for not loading tools completely in the context.
There’s nothing really strange about it. It’s just a protocol update issue.
The MCP standard will and has to evolve to address this context issue. It’s a no brainer and this is a perfect example of the direction mcp is going / will go.
There’s fundamentally nothing wrong, it’s just protocols updates that have to occur.
In also interested in n8n. From what I gathered it’s a everything baked in app, not a lib. Meaning that unless you re doing upstream contributions you don’t actually code anything. Just manage big configs. How are you planning to use this toolkit with it?
I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?
I'm super confused as well.
This seems like exactly that, just some default prompt injections to chose from. I guess I kinda understand them in the context of their claude chat UI product.
I never understand why there's always one of the top comment on every Go post being derogatory and mentioning Rust. It never fails.
It starts to feel like a weird mix of defensiveness and superiority complex.