Show HN: Gitdot – A better GitHub. Open-source, written in Rust

FWIW I've noticed that agents are pretty good at writing "High-Level Rust" for most basic applications, which gives you pretty great performance (orders of magnitude faster than RoR), great deployment, probably great security if steered by a senior, and pretty great maintenance again if originally steered by a senior. I feel like this is a not-so-secret secret.

I personally won't be using dynamic languages for anything but toy scripts now. (well, except JS, which is hard to avoid with the massive size of WASM bundles)

P.S. I assume Go is still great as well, but IMO Go no longer has an identity. What are they going for anyways? Garbage collected rust? "How to invent a perfect niche and then throw it all away in 21 days". /rant

I am indeed curious to see how an agent-coded project turns out in the long term.

Coherencey from LLMs decreases as the source increases in volume, waiting to see how this all turns out.

I am not a rust evangelist, I am not a rust programmer or programmer at all; however while evaluating tools to use, anything written in Rust and Go at-least gets me to look at the project in more detail, since they most likely are able to ship statically linked binaries, which has been one of the key criteria for my personal evaluation of tools to select and use.

So, you might not consider it as a valid signal, however it might be for other users. Even if it has a negative connotation for you. Which in itself, again might be a good filter in case you don’t want to use it.

> 7. How does gitdot make money?

> We don't.

> We are fortunate enough to have raised a small pre-seed round from investors we are happy to call friends, and also to be at a point in our lives where we are financially independent and in good health.

The founders of Artifact said the same thing. They had no plan to make money and once they used their own capital they decided not to continue running it anymore (no-one else wanted to invest in Artifact).

So it is only a matter of time until they eventually need to make money, raise money or shut it down.

They claim it is better just because of the language, ignoring the features gap, the size of the team developing and supporting the software and not having solved any issue with the software they compete against.

And to be clear, this in not in favour of GH, it is against the mentality that the programming language makes better products and programmers.

only for very few companies, memory safety issues are a thing. most of those dont use rust because it lacks tooling and certification paths -_-.

rust is like AI and cloud. heavily marketed, not bad, but not as good as whats on the box -_-. it makes life usually harder for a lot of aspects (ofc cleverly avoid in publications about it -_-)

Fast, Safe, Lightweight, Statically linked (plop a precompiled binary in ~/.local/bin and run it), few/shallow dependencies, senior developers, "Done" software.

Now, certainly no guarantees, enough counter-examples, I know. And attributes that one can get with anything from PHP via Javascript to Lisp as well. Some attributes have stronger correlation than others too.

But, in general, "rust" has a (much) higher chance of meeting these attributes. I care about those attributes above anything else.

In reality, the programming language tells you all kinds of subtle things: probabilities about the way the software will feel to use, how stable it’s likely to be, how fast, what the author is likely to focus on.

I found one of the best jobs of my life in 2015 by asking “who’s doing interesting things in Atlanta in Go?” Not because I was uncompromisingly settled on Go, but because in 2015, using Go (often) connoted a certain approach, a certain type of engineering, a certain constellation of values.

So please stop pretending the whole gestalt of programming languages and their communities don’t deeply affect the resulting software.

(I say this with no unkindness intended, mostly to all of hackernews)

Recently encountered someone going 'full crab' with rust & vk trying to chase perf, they were not happy when some thoughtfully written modern JS beat the brakes off it even with the overhead of the browser (~2000fps vs 750)

This kind of thoughtless "its rust!!!" shit causes people who don't know better to waste time chasing their tails. Claude seems to encourage it :\

/s, I love zig, but I'm consistently surprised of how popular any post containing zig in the title makes it to the front page almost daily, doesn't happen with any other language.

i'm not aware of the old macOS inspector pattern, but this sounds super interesting and i agree with the critique of inconsistency in github's behavior.

this reminds me a tad of superhuman's right panel too which auto-populates upon writing a time (or typing a name i believe?), which is a feature i do find personally useful as well.

i haven't thought seriously about hovers on nouns quite yet, but this is giving me much to munch on.

thank you sincerely this is dope.

i will also say on accessibility, i recognize the site is a bit too small font in general — and will fix it soon.

I really hope it works out, would bring so many benefits.

[0] https://codeberg.org/ForgeFed/forgefed

a lot of this we've really come to know as we dug into both it, gittea, gitlab, and all of their internals.

i think the short answer as to a differentiator is design. our goal's to just build the best product possible, one that we'd love to use and one that we hope developers do too.

some of the stuff we've been thinking about include: stacked diffs as PR primitive, a Nix-based CI (that's reproducible and locally testible), a super simple and intuitive bug tracker, and just making the site super duper fast and pleasant to use.

that is to say, there is a _lot_ of surface area that a software forge covers and i think there's a lot of room to make things better.

hope that's clear enough, apologies for any ambiguities, we do NOT have all the answers quite yet haha

Downvote me into oblivion or whatever: It's not relevant to me in the slightest whether you built it in Rust or not, or even Python, Go, Java, Node, PHP etc. There is lots of great and terrible, fast and slow software written in each. OP might only have 3 months of programming experience for all I know.

Why is "made with Rust" any more relevant than "made with Go" to an end user of a software product? It just doesn't matter.

glad to hear the positive feedback :)

> The problems I kept running into:

> - I'm lazy.

That should tell you all you need to know about this super hype new fantastic GitHub written in Rust ! ! ! !

hope our sentiment is clearer in the comments that i've made, i think i've made the mistake of phrasing here with the "anti", i'll revisit it.

edit: dang has removed it, apologies for the confusion i caused, that was my mistake.

It might be a bit difficult to self-host at the moment (as we don't have a good documentation to do so) but you can try and let us know how it goes.

i debated this for a while too, some of my thinking for how it is is that i wanted the focus of a repository page to be _the repository_. so as much as we can, trim things that might detract.

it was also done with the intention that it's actually pretty rare for a user to find or explore repositories on github (more likely you find them here on hn or on twitter), so had the restraint of really trying _not_ to make gitdot anything like social media.

but thank you nonetheless for the feedback, i'll revisit it proper and see if i can make this more intuitive.

But you are squinting really hard if you equate "programmers not being good lawyers" with "they obviously vibe-launched the product".

i replied in a separate comment: https://news.ycombinator.com/item?id=48452052 but to reiterate: 1) no AI copilot and 2) no training or selling of your data.

but overall, the general ethos is to focus on the problems that AI is introducing as of now and how we can help solve them, rather than just build AI features with abandon assuming that they're good.

some stuff that we do know about: the influx of slop PRs / slop issues on popular repositories, losing agency our own of code as we AI generates more, and privacy/sovereignty of code.

i've talked a bit about stacked diffs which we do see as one concrete stab in that direction, but a lot here is to be admittedly sketched out.

it's very convenient to be sent a link (or find it on hacker news) and to be able to click around files, read the README, understand what a repository is about without having to clone it and open locally. plus -- if you only need a barebones git server with no web UI, git provides this by default.

if the question is, will you build a CLI / what will be in it? the answer is yes, we do have a barebones CLI for auth as of now, do envision things like managing issues / PRs from the CLI, but want to make sure that strike the right balance there.

i think TUIs can be deceptively hard to build well, and admittedly, it hasn't been a priority for us quite yet.

Don't try to make me install a random program if I can view it in my sandboxed browser safely.

Also, browsers have greasemonkey to help me personalize websites easily. TUIs don't.

https://gitdot.io/bkdevs/gitdot/files

so take this to mean - 1) no AI copilot in the app and 2) no training on your data nor selling of it.

our take on AI is that we should focus on building tools that help address its limitations; one of the things we're particularly keen on is building stacked diffs into reviews as a primitive, so it's easier to review a large AI-generated (or assisted) PR. (e.g., diff 1 for API changes, diff 2 for backend wireup, diff 3 for front-end changes)

i think to do that, we're going to try and hook into the subscriptions that people already have and are paying for: Claude, Codex, rather than package our own, but some of that is a bit hacky to do.

hope that's clearer and thank you for asking

That sounds more like anti-enshittification.

If you are YC backed then say "YC Winter 2026" or whatever in your title frankly - people will work it out anyway.

They said it was a better GitHub, which is a very high bar (despite the regular complaints about GitHub). They also said it was anti-AI, despite it being vibe-coded.

Also, know your competitive space. Posting on HN is like pitching - not knowing about your competitors is not really going to work - you need an answer for, for example, why someone picks Gitdot over SourceHut.

my fixation here is to make everything load instant, but that is dependent on server latencies, which right now is admittedly slow as we only have one server in the US.

but thank you for giving it a shot nonetheless!

You'd want something that doesn't allow training on private repos, so ideally not a private company that can change owners and managers and hence policies over time.

It's an interesting business case - open source website, revenue generating with some type of "open" business structure.

Its first repos could be of itself.

I had this idea for enabling pull requests to be in "pipelines" with each request crowd-funded (as an option) to thereby entice action. A small split could return to the main site itself for upkeep.

but i will say that the point of our post isn't to really sell anyone here or on anything. we kinda know that our product as-is isn't ready to use at real scale (we lack issues, prs, ci, gotta fix a lot of bugs, etc.)

we did just want to sincerely share what we built. and rust is a part of that, we chose it cause we wanted to learn it and we then quickly found out that we really liked it too.

What an irony that those exact safety guarantees that made it attractive are now a detriment because they make the project smell like AI.

Surely it is at least in part. We're talking about the announcement of a new open source project that isn't ready to use yet which would presumably enjoy people helping make it work for them, and a new startup around that open source project that is likely to be hiring in the future (or even maybe right now? Didn't check).

> Why does it matter from a user perspective

It implies that there was likely a small degree of rigour in the construction... not a large one (very little software has that)... and not a guarantee... but likely more than the abysmally small average in the software world.

yeah, that admittedly is not priority, but thanks for taking the time to check it out.

This particular issue is solved in GitHub proper, and derives from the Windows 95 tree view widget [1], which I seem to remember from Windows 3.x but can't find a screenshot.

The hover behavior is just not an intuitive or accessible default. I can't imagine someone being able to use this if they have a hard time clicking without moving the mouse. It also wastes resources fetching file/directory contents while the user is moving the cursor to a predetermined file they presumably wish to open.

[1]: https://learn.microsoft.com/en-us/windows/win32/winauto/syst...

and yeahhhh, i do try to be very non-marketing in all that i say, but something about the title made me a bit ambitious, apologies.

"Don't be snarky."

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

Obviously this is a project at an early stage and the title expresses what they're working on, not a claim to 100% feature parity.

https://news.ycombinator.com/newsguidelines.html

Well actually, spacex owned xai is now coding AI in C while earlier it was rust; I guess with the attitude that a language good enough to control rockets is fine for ai.