siddontang

wuren Verified account @wuren463338 · 2d

其实现实也有一个很有趣的错位。
现实中99%的项目不会超过几十万行的级别，而却有更多的声量去支持rust这种为百万千万行以上项目设计的语言。
现在AI的存在，几十万行的Cpp代码基本不会有内存安全问题，甚至有时可以放手让AI去改一部分几百万行级别的代码。
因为大代码量的工程不可能是高耦合的，局部性一般都比较好，AI目前的上下文基本能处理。
这种情况下rust以后不可能取代cpp在基础设施和各种垂直领域的地位。但rust有一点好处就是社区很活跃（先不说有多少vibe safety，就问你活不活跃吧），可以无包袱地渗入cpp和其他语言渗透不够的领域（虽然也没多少了）。
rust因为社区狂热所以才能存续。
尽管精神对内存安全，高性能和所有权设计狂热，但肉体已经和cpp没有区别了。更别说vibe safety，和cpp一样越来越多的包袱，更高的耦合度与上下文污染，难以进一步优化性能…
说到底，是cpp老了，cpp人老了。

View quoted post on X

github.com GitHub - ngaut/agent-git-service: Reimplement GitHub for Agents. Reimplement GitHub for Agents. Contribute to ngaut/agent-git-service development by creating an account on GitHub.

Arpit Bhayani Verified account @arpit_bhayani · 3d

GitHub is rebuilding how it stores Git repositories because of, well, AI agents. They published a blog post about it, and one idea that was very insightful was how it makes reading nearly free when nothing has changed. Here is how it works...

Today, even a very busy repository sees at most a few dozen writes per second. With hundreds of agents pushing to the same repository, GitHub wants thousands per second. Before we dig in, let us understand what a reference is. In Git, a reference is a name that points to a commit, like a branch:

- `main` points to commit `a1`
- `fix-login` points to commit `b1`

When you push, you add your new commit and then move a reference to it. For example, pushing to `fix-login` changes it from `b1` to `b2`. The push is only complete once that reference is updated.

When someone clones or fetches, the server cannot send anything until it looks up what each reference points to. "Give me `main`" means nothing until the server knows `main` is at `a1`.

GitHub first tried two designs for storing references on plain object storage:

- Keep all references in one log file. Reading is easy, because everything is in one place. But every push has to wait its turn to write to that one file, so it topped out at a few hundred writes per second.

- Split references across many files. Pushes can now write in parallel. But to get the full picture, a read has to check every file, so reads became slow.

Each design speeds up one side and slows down the other. So the team built a dedicated replicated log called Ref-CAS to track references. It does two things:

- Writes lock only the references they change. A push says "move `fix-login` from `b1` to `b2`, but only if it is still at `b1`", and only `fix-login` is locked while that check happens. An agent pushing to `add-tests` is not affected. Agents mostly push to their own branches, so they rarely wait on each other.

- Every successful change gets the next number. Moving `fix-login` is change 101, and creating `add-tests` is change 102. The version of the repository is the latest number, so it is 102 now. Ref-CAS can tell exactly what anyone holding an older number missed.

Now, how does this make reads faster?

The replicas that serve requests keep a local copy of the references, tagged with the version they last saw. Here is an example:

1. A replica has a copy at version 100: `main` is `a1`, `fix-login` is `b1`.

2. Two agents push at the same time. `fix-login` moves to `b2` (version 101), and a new branch, `add-tests`, appears at `c1` (version 102).

3. A read arrives. The replica asks Ref-CAS: "I am at version 100, anything new?"

4. Ref-CAS answers with the updated references and the new version, plus pointers to any pack data the replica needs: `fix-login` is now `b2`, `add-tests` is `c1`, and the version is 102. The replica updates its copy.

5. The next read asks "I am at version 102". Ref-CAS says "yes, you are current" and sends no references.

So when nothing has changed, a read costs one number comparison. The replica does not need to check every reference or every segment, which was the problem with the second design.

With the new architecture, GitHub reports 7,200 pushes per second to a single repository in internal tests, with 5,000 agents pushing at once.

Classic solution to a classic problem.

View quoted post on X