21–30 of 36 posts
But would you mind renaming the packages to make it clear they aren't official, before too many people depend on them? Prefix with your name or "currentspace" or something?
I'd just hate for it to be a big mess later if we ever decide to release an official implementation (and if it's not based on yours).
I would recommend not having an AI write your README. Even if you didn't use AI for coding at all and the code works perfectly, it really doesn't inspire confidence.
The commit names look very weird too, feel more like marketing speak: > BREAKTHROUGH: Fix critical ID mismatch in Cap'n Web protocol > TIER 3 ULTIMATE: Extreme Stress Tests & Advanced Capability Composition > Achieve Cap'n Web protocol mastery with perfect capability composition (note: this exact commit name is repeated another time) The commit descriptions are even worse. If they’re so blatantly not written for anyo…
"I built" more like claude-code built. Also I don't know what the rush is to get a shiny new Rust implementation out asap that you need to vibe code the entire thing. The Github stars couldn't be that serious. Also the disclaimer at the end "Built with Ready for production use is a strong strong claim when the entire thing is vibe-coded.
Regarding the concept, it's cool to see you using LLMs to quickly generate protocol versions. But asking the community to review an AI-generated implementation week-old announced protocol, is more or less putting the recently coined-term AI "workslop" upon others. It doesn't really matter if it happens to be a good implementation or not. There are two main issues I can think of right now: 1) Work going into the proto…
Regarding the concept, it's cool to see you using LLMs to quickly generate protocol versions. But asking the community to review an AI-generated implementation week-old announced protocol, is more or less putting the recently coined-term AI "workslop" upon others. It doesn't really matter if it happens to be a good implementation or not. There are two main issues I can think of right now: 1) Work going into the proto…
The protocol is boring, in the best sense of the word. It's simple, straightforward and well specified externally ( https://github.com/cloudflare/capnweb/commits/main/protocol.... ). IMO, there's little value in reusing protocol wrangling code.
I am so pleased that people find it boring! It was quite a puzzle to whittle it down to that point from the original monstrosity: https://github.com/capnproto/capnproto/blob/v2/c%2B%2B/src/c...
I mentioned in the README that I leaned heavily on Claude Opus for the port. One of the biggest challenges was tamping down its default “everything is production-ready in a week” optimism. That said, I also discovered along the way which guardrails worked and which didn’t for guiding it toward a compliant implementation. It was good learning, and honestly, fun.
I’m genuinely interested in the Cap’n Web protocol. Writing this in Rust gave me a much clearer sense of where I would and wouldn’t use it. Credit to the Cloudflare team for defining the protocol and shipping a solid reference implementation, this wouldn’t have been possible otherwise.
A good example of why a second client (even one bootstrapped with AI) is useful: in implementation I ran into a spec ambiguity around array escaping (documented here: https://github.com/cloudflare/capnweb/issues/68 ). My initial Rust serializer emitted unescaped arrays at lower levels, and I even patched the TS reference to accept them. In the end, escaping arrays at all levels turned out to be the cleaner and more consistent approach, so I’ve recommended that clarification in the issue.
On naming: fair point about possible confusion with Cap’n Proto. If the Cloudflare team ever wants the crate names for an official Rust impl, they’re theirs. If there’s interest in pushing this to production ready quality, I’d also be glad to put in the work.
Thanks again for the constructive input. Happy to dive into technical details if folks are curious.
OP here. Thanks for all the thoughtful feedback, I really appreciate it. I mentioned in the README that I leaned heavily on Claude Opus for the port. One of the biggest challenges was tamping down its default “everything is production-ready in a week” optimism. That said, I also discovered along the way which guardrails worked and which didn’t for guiding it toward a compliant implementation. It was good learning, an…
Regarding the concept, it's cool to see you using LLMs to quickly generate protocol versions. But asking the community to review an AI-generated implementation week-old announced protocol, is more or less putting the recently coined-term AI "workslop" upon others. It doesn't really matter if it happens to be a good implementation or not. There are two main issues I can think of right now: 1) Work going into the proto…
The protocol is boring, in the best sense of the word. It's simple, straightforward and well specified externally ( https://github.com/cloudflare/capnweb/commits/main/protocol.... ). IMO, there's little value in reusing protocol wrangling code.
"I built" more like claude-code built. Also I don't know what the rush is to get a shiny new Rust implementation out asap that you need to vibe code the entire thing. The Github stars couldn't be that serious. Also the disclaimer at the end "Built with Ready for production use is a strong strong claim when the entire thing is vibe-coded.
The two big signifiers that something is "ready for production use" are: 1) it has been successfully been used in production at some scale for a while, and 2) it has some commitment to API stability. A 1 week old project on version "0.1.0" is neither, whether vibe-coded or not.
"I built" more like claude-code built. Also I don't know what the rush is to get a shiny new Rust implementation out asap that you need to vibe code the entire thing. The Github stars couldn't be that serious. Also the disclaimer at the end "Built with Ready for production use is a strong strong claim when the entire thing is vibe-coded.
Did you look at the code? There's probably AI slop in the unit tests or other ancillary code, but the API and core code show obvious signs of significant care and attention. I couldn't find evidence of the kind of slop Claude can create in rust in the 2 source files I looked at. Vibe-coded means not looking at the code, this is very obviously not that.