Pinned Tweet
We just built the most scalable Git server out there: 7,600+ concurrent pushes/s per repo at millisecond latency.
Powered by Raft and S3, designed like a modern database.
Today we're making it open source by releasing Enroute 0.3.0.
Read the write-up: enroute.sh/blog/everyone-is-…
Sam Reis retweeted
This kind of feedback makes my day! ♥️
Super cool to see people building their own code forges on top of @enroute_sh.
We’ve also built our own forge for dogfooding Enroute, so it works exactly the way we want. The UI is super clean, and instead of PRs we have a simple breakdown and summary of everything your agent changed.
Fun fact: It runs on a single @flydotio machine and is still the fastest thing out there.
Congrats @tangled_org on the launch! 🚀
We spent the last few months building the first ever truly federated code forge. Tangled is self-hostable, hackable & extensible.
The future of software engineering is a moving target -- our bet on open protocols gives us the agility to move with it.
tangled.org/blog/forge
Sam Reis retweeted
Nice comeback from @github after the (re-) launch of @GoEntire this week. Seems like 7k+ pushes/s is how you build Git infra these days.
Go check out @enroute_sh if you want to build on open-source git infra with that kind of performance already today!
Just released Sirocco 0.3.0: no longer just a decompressor, it now also supports fast, no-unsafe streaming DEFLATE compression.
In fact, it surpasses almost all existing compressors on the Pareto frontier on my M4. The final boss libdeflate is still better in some cases. WIP.
Whenever you‘re dealing with Git objects, (de)compression shows up big time in cpu profiles.
I just open sourced sirocco (github.com/srijs/sirocco) which for avg git pack parsing is now the fastest streaming inflate lib that I know of.
Ships in our next release.
Fast writes to disk quorum with delayed S3 persistence is where it's at. If you want the same for your Git hosting, check out @enroute_sh.
Rivet 3.0 is built on S3
But we did something completely different...
And oohhhh boy:
- 6.9 ms actor cold starts (durable)
- 0.69 ms SQLite writes (3 availability zone)
- 0.20 ms SQLite reads
Here's how we built our new storage engine, WarpDrive.
~~~
Most S3-backed database read & write straight to S3.
That means:
- Every commit & cache miss is an S3 request ($$$)
- S3 downtime takes you down (SLA allows 8 hours downtime/yr!)
- S3 Express is limited to one availability zone
This usually ends up slow, expensive, and has poor tail latencies.
For Rivet 3.0, we decided we could do better. We wanted 3.0 to ship with:
- SSD speeds with storage on S3
- Stateless nodes
- No dependencies
~~~
To do that, we built WarpDrive to durably write your data on fast disks *before* we write it to S3.
Every write on WarpDrive is:
1. Written to disk in 3 availability zones
2. Acked once a majority has them
3. Then batched to S3 in the background
That means that Rivet has:
- Writes that get durably acknowledged insanely fast
- Fewer S3 operations by batching in the background
- Survives S3 outages for new & warmed actors
- Nodes remain stateless
- S3 is the only dependency
~~~
WarpDrive is something we're incredibly proud of and can't wait to have you try for yourself.
Rivet 3.0 with WarpDrive is in preview today. It's available on Rivet Cloud or for self-hosting today.
Please send feedback on X, Discord, or DMs -- we want to hear anything and everything you have to say (please bump me if I missed a message!)
There should be no reason to vendor lock yourself to Cloudflare Durable Objects if you can have better performance, better DX/AX, lower cost, and more flexibility on software you own.
And of course, it's all open source.
Did you know @enroute_sh is the fastest git server, no matter how you run it?
Our internal dogfooding forge runs on a single Fly.io machine and still beats any other Git hosting solution.
The @enroute_sh Git server is not only extremely fast but also fully programmable. Start it with a single command on your machine and build against it. Self-host it on your own VPS or deploy it as a multi-Raft cluster for high availability. Any setup is just a config change on the same binary.
Read our blog post to get the details! enroute.sh/blog/four-ways-to…
Sam Reis retweeted
so many gems and great tips in this talk from @yminsky about how to improve your codebase for agents
• agents thrive on feedback, and types are one of the best kinds
• make illegal states unrepresentable with types, and it enforces global rules across your codebase
• property based tests, fuzzing, and even full-system deterministic simulation testing
• expect tests: just print stuff out and capture it in the test. makes behavior legible. it's very similar to how compilers have fixture tests, it reduces the review surface area
• formal methods used to be very expensive: seL4 is about 8,700 lines of C and took around 25 person-years, with 23 lines of proof for every line of C code, but agents change the roi
youtube.com/watch?v=rUYP4C29…
Sam Reis retweeted
We’re launching incident management in @openstatushq. Built for small teams that live in Slack.
Live on Product Hunt today. 🐱
producthunt.com/products/ope…
Sam Reis retweeted
After 5 years in v0, it's finally happening.. Dagger 1.0 is in beta and we need your help testing it.
If you've tried Dagger before, a lot has changed... We've been cooking.
Announcing Dagger 1.0 beta.
Replace Jenkins and GitHub Actions with CI that matches the speed and scale of coding agents without wasting compute or tokens.
Featuring: test-native CI, dev shells, local and remote execution, official modules, and more.
dagger.io/blog/dagger-10-bet…
OIDC is straight up the best thing to happen for machine to machine auth, and should be everywhere.
Death to long lived api tokens in secret stores.
Despite of all its downsides, I keep coming back to working locally because the code review experiences are simply 100x better than any crappy browser-based diff viewer. This too looks awesome.
I’m considering unshipping git thin-pack support in the next version of @enroute_sh. The reason might surprise you.
Thin packing is when we delta encode against objects that the client already has. This is most often the case when you do a git pull to catch up an existing repo.
What this means is that even though Enroute responds in a third of the time, we lose e2e bc the client spends almost 2 seconds fixing up thin bases on a single thread.
Shout out to Gitoxide here btw where this is much better and thin bases are actually faster too.
Sam Reis retweeted
isn’t it beautiful the competition that ai has enabled?
we have people trying to build more scalable git, postgres, sandboxes… the result of that competition will benefit our entire industry, and this wouldn’t have been possible years ago
Whenever you‘re dealing with Git objects, (de)compression shows up big time in cpu profiles.
I just open sourced sirocco (github.com/srijs/sirocco) which for avg git pack parsing is now the fastest streaming inflate lib that I know of.
Ships in our next release.