Gitdot is an early open-source software forge. Today it supports signups, orgs, public and private repositories, and GitHub imports as mirrors or migrations. It does not yet have issues, pull requests, CI, mobile support, or even plain Git-over-SSH. The founders framed it as a faster, more keyboard-driven alternative to GitHub, with a web UI inspired by terminal tools and a backend written in Rust.
What landed with readers was not the Rust part. It was the gap between the pitch and the product. “A better GitHub” read as overclaiming for something that is currently closer to a stripped-down repository browser than a GitHub replacement. The UI split people hard. Some loved the dense,
CLI-like layout and said it felt refreshingly fast and readable once they adapted. Many more said the basic affordances were off, inputs and buttons did not look interactive, fonts were too small, file preview on hover was distracting, and the lack of mobile support made the launch feel unfinished. Several people also reported slow loads, CPU-heavy behavior, or janky transitions, which undercut the central promise of speed. The founders were unusually responsive and patched a few issues live, including the hover-preview behavior and missing email auth records.
The other big reaction was to positioning. “Written in Rust” drew eye-rolling from people who saw it as empty signaling unless tied to a concrete user benefit like static deployment or lower operating cost. The same thing happened with the original “anti-AI” framing. Once readers looked at the public source and saw Claude-related files, the claim collapsed into a narrower point the founders later clarified: no built-in copilot and no training on user code. That clarification was better received, but it reinforced the broader complaint that the launch copy was trying to borrow credibility from culture-war labels instead of from product facts.
The more useful thread settled on strategy. Competing with GitHub is not mainly about rendering repo pages. It is about collaboration features, scale, trust, ecosystem gravity, and a business model that will still exist after users migrate in. People pushed the founders to explain why this should exist next to Forgejo, Gitea, SourceHut, and other forges instead of contributing there. The answer that came through was autonomy over design and product direction, plus a bet that there is still a lot of room to improve code review, CI, and overall responsiveness. The strongest positive read was that the interesting part here is not “GitHub in Rust” at all. It is the attempt to rethink forge UX around speed, inspection, and keyboard-centric navigation. The strongest negative read was that this is exactly the sort of product where ambitious branding gets punished if the basics are still missing.