JyB

Have you considered submitting an upstream patch to the widely used actions/setup-go as well?

You can blame the media and journalists with sensationalist headlines

Life is not intelligence.

Why would weights need to be « loaded again » for the 2nd pass? Weights never change at inference time no?

One can hope that the Go maintainers won't keep caving as they did for generics.

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.

No. You're down a very bad path if you 're seeking that.

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.

No thanks. Reduced feature-set is the appeal.

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.

What credentials related to software engineering? Please expand and do not post nebulous comments like these.

Courage is not the appropriate word

This specifically is super annoying.

Restrictions don’t have to be confusing, they can be clear. You are missing the whole point.

> 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?

I don’t know if you’re being serious but that’s laughable

I’m genuinely not sure if that post is supposed to be some funny parody. Either way I did have a good laugh reading it.

How is that specific to antigravity? Seem like it could happen with a bunch of tools

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?

Concurrency. Unless you’re happy stopping the world on llm io… Go excels at handling network calls and the like. It’s basically what agents are.

I think you are right.

Claude Skills just seem to be the same as MCP prompts: https://modelcontextprotocol.io/specification/2025-06-18/ser...

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.

By I don't understand why it's a thing in Claude Code tho when we already have Claude.md? Could also just point to any .md file in the prompt as preamble but not even needed. https://www.anthropic.com/engineering/claude-code-best-pract...

That concept is also already perfectly specd in the MCP standard right? (Although not super used I think?) https://modelcontextprotocol.io/specification/2025-06-18/ser...