Show HN: Gitdot – A better GitHub. Open-source, written in Rust
Posted by baepaul 1 day ago
What works now: user signups, org creations, private/public repos, and importing GitHub repositories (both as read-only mirrors and full migrations). So basically, you can create, push and pull to a repo, but we don't have many features quite yet (issues, PRs, CI).
What is a bit unique is: 1) we built it in Rust and 2) the website is a little odd. Its design is inspired by CLIs (e.g., fzf, broot, vim) instead of web apps, and as such, lacks some affordances that you might typically expect in favor of keyboard-driven instant navigations (we have the very ambitious goal of an FCP of 100ms). In case you're curious, here's how we we built it: https://gitdot.io/designs
We recognize that we're making some bold claims here and are also well aware that we have much to learn. Building software is still hard, and that's a fact we seem to relearn everyday.
But we wanted to share what we built so far nonetheless.
Cheers, thank y'all for reading, and till the next —paul & mikkel.
Comments
Comment by usrbinenv 1 day ago
Second, when I browsed from an actual desktop, and clicked on links for files it was all slow as hell - specifically the part when you click on a file an expect it to just load, you instead get: 1) some layout switch which looks like page reload 2) then it says "loading..." for several seconds.
After looking at the source code, it appears to be React or similar frontend framework... Ugh. I don't know why people choose to use that stuff, just have a regular SSR which would work a hundred times faster and is more pleasant. And if you really want an SPA, don't use React, Vue or Svelte (and similar), it's horrible and always slow.
Finally, since this appears to be a YC company, it shouldn't matter what's it written in. In fact, I don't even know why Rust would be a good thing here when Go or even Rails/Django would work just fine - but again, it just reinforces the meme that if it's written in Rust, you'll surely hear about it.
Overall, the minimalism idea is welcomed, but it supposedly should appeal to people like myself and it doesn't for all the reasons I mentioned above.
Comment by xp84 1 day ago
Comment by johnisgood 1 day ago
Comment by Semaphor 15 hours ago
Comment by johnisgood 13 hours ago
Comment by rapind 9 hours ago
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
Comment by gritspants 6 hours ago
Comment by rapind 5 hours ago
It's probably polarizing and I honestly don't know why I felt the need to rant about it. /shrug
Comment by kode-targz 20 hours ago
Comment by smetannik 21 hours ago
Comment by lelanthran 19 hours ago
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.
Comment by devsda 14 hours ago
I wonder if feature velocity closely tracks LLM context management innovations.
May be this encourages more modular systems if those improvements can't come fast enough.
Comment by boxed 11 hours ago
Comment by analog_daddy 20 hours ago
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.
Comment by cztomsik 15 hours ago
Comment by cocoto 13 hours ago
Comment by echoangle 12 hours ago
That’s not what clickbait means at all.
Comment by senordevnyc 11 hours ago
Clickbait (also known as link bait or linkbait) is a text or a thumbnail link that is designed to attract attention and to entice users to follow ("click") that link and view, read, stream or listen to the linked piece of online content, being typically deceptive, sensationalized, or otherwise misleading.
Comment by insanitybit 12 hours ago
Comment by alexpadula 20 hours ago
Comment by jvanderbot 13 hours ago
Comment by 1dom 16 hours ago
How can you still not see any advantage? Or was the point of your comment to say that you think the only real motivation is self or Rust promotion, suggesting some dishonesty amongst the people you're responding to?
Comment by giancarlostoro 19 hours ago
Comment by jvanderbot 13 hours ago
But the "Written in rust" stuff comes with so much falsehood baggage about automatic best-in-class performance, automatic perfect safety, automatic rigor, that it is detrimental to just say "written in rust" and not provide a more nuanced statement about why that's good (or just drop it as a headline item!). You might not agree because you can single out one automatic benefit of rust b/c of Cargo (not rust), but even that is suspect b/c Rust can ship with dynamic libraries if configured to do so.
In this case, the credibility and benefits are clearer if they said "Static binary". This is all just context. If you see a benefit to that headline, that's ok.
Comment by altmanaltman 20 hours ago
You might have better devops experience as an end-user of the said software if its statically linked and its a good trend in software sure but it is not unique to go or rust.
Admitting you don't know how to code and still trying to argue rust is better is just wild sorry.
Comment by zamalek 20 hours ago
C and C++? You've got to be joking. If the project provides static binaries, sure, but I don't want to have to worry about finding a necronomicon and summoning the correct kind of imp required to properly use whatever insane build system the project is using.
Comment by altmanaltman 20 hours ago
Its like saying "I want a red car because it goes fast" when people are actually disucssing how the engine works or how easy/difficult is it to drive etc.
You cannot base your like/dislike on that single criteria and expect that to actually make sense.
Comment by dijit 18 hours ago
For some people, Linux package management is not solved. Static binaries at least work for deployment.
More useful for client software, but you can’t just dismiss someone for having this preference given the poor viability of running arbitrary binaries on Linux due to GNU’s userland style.
Comment by johnisgood 17 hours ago
Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.
Comment by johnisgood 17 hours ago
I noticed your comment is getting downvoted. I wish I knew why though. Is it because of your analogy? Is it because they think that somehow "single binary" has anything to do with the programming language? Would like to know. I am not going to assume that it is a confirmation of what I wrote earlier.
Comment by CobrastanJorji 18 hours ago
Comment by insanitybit 12 hours ago
Comment by nananana9 17 hours ago
Literally last week I was porting something to Linux and had to rewrite the libwayland build scripts because they only expose a shared object.
There's also an expectation that you're going to install them via your system's package manager, not build them, so a lot of them use insane build systems (autotools, meson).
Comment by pastage 17 hours ago
For me install size matters and statically linked stuff are too big sometimes. Of course a 100MB go statically compiled binary has huge advantages now days.
Comment by berkes 15 hours ago
Huh? It does. Only libc is dynamically linked, by default, which --iirc-- all programs will commonly need anyway. All the rest is statically linked.
In fact, it takes some hoop-jumping to build dynamically linked binaries with cargo.
Comment by johnisgood 15 hours ago
I am not going to pretend I know Rust enough to comment (yes, would be a minute check), I was just commenting on the "Only libc is dynamically linked" bit.
Comment by berkes 15 hours ago
edit: Ironically, that makes shipping the binary a tad harder, since this "linux" version won't "magically" run on about every Linux, or mac version on mac, etc. I guess that's why its not the default, though that's just me guessing.
Comment by johnisgood 13 hours ago
Comment by badsectoracula 16 hours ago
Personally i do not even write Go myself yet when i see some webapp made in Go i'm pretty much always sure that it'll be a self-contained static binary. Yes, there are probably exceptions (and i haven't surveyed all webapps made with Go) but it has been common enough to feel as the standard approach to me - and if i ever decide to make a binary webapp, i'll probably reach for Go to do it.
Comment by thayne 17 hours ago
Comment by TeriyakiBomb 14 hours ago
But for sure a systems language is going to be far faster on paper and Rails is far from perfect and does have some performance foot guns you need to avoid. And yeah, architecture is everything.
Comment by epolanski 17 hours ago
GitHub is so data heavy and there's so little reactivity that it should really be server side rendered.
Comment by IshKebab 16 hours ago
Comment by ClikeX 16 hours ago
But Rails was SSR by default, and most of the frontend was just Embedded Ruby (ERB) template files all over the place. And way back when, it was even relatively common to use Javascript supersets like CoffeeScript[1] and Opal[2]. The latter being Ruby that compiled to JS.
[1]: https://coffeescript.org/ [2]: https://opalrb.com/
Comment by TeriyakiBomb 14 hours ago
Comment by pdpi 16 hours ago
Comment by ottavio 18 hours ago
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.
Comment by olzhasar 17 hours ago
Nowadays when everyone and their dog are either vibe-coding with Rust or constantly shouting about it's superiority, I've lost any interest in the language. I'm learning Zig.
Comment by lioeters 15 hours ago
Zig, on the other hand, is a breath of fresh air. There's so much to love about it, including language design that values clarity and simplicity, and the cross-compiler which is how I got started on it, by using Zig as a better build system for C projects. Their move away from GitHub and vibe-coded contributions is also commendable, it's more reason I trust their sensible judgement.
Comment by mapcars 1 hour ago
None of this makes Rust worse as a language
Comment by baq 16 hours ago
Comment by dudisubekti 17 hours ago
Comment by ClikeX 16 hours ago
Keep in mind. Learning a language usually also means you interact with the people in the ecosystem at some point.
Comment by dudisubekti 14 hours ago
https://www.reddit.com/r/rust/comments/1tcrmjs/rewrite_bun_i...
Many seems to be very skeptical and concerned about Bun being vibecoded.
The rest of the subreddit is basically people showing off their work.
Comment by ClikeX 14 hours ago
You can make the case that if something like this turns you off from diving deeper into the language you probably weren't that motivated to begin with. But it is a noticable effect. This post isn't the first time I see it either. Rust has become a meme amongst my colleagues because things keep popping up with "Build with Rust" before mentioning anything of substance of the project. The phrase "Did you know Rust is memory safe?" is also a running joke in my IRL dev surroundings now.
Comment by dudisubekti 13 hours ago
Also if we're only judging whole communities by their toxic minorities, then... I'm so sorry Americans reading this, I've got some bad news for you, lol
What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
Comment by macintux 10 hours ago
Comment by bwfan123 9 hours ago
I have seen developers and managers having an attitude of arrogance just because they happen to code in a specific language. They also look down upon other developers just because they happen to code in some other language. Evangelism combined with arrogance is toxic.
Comment by monster_truck 11 hours ago
Comment by bwfan123 8 hours ago
Reminds me of a colleague who rewrote the entire standard template library from scratch to demonstrate his uber-templating knowledge. He was the only one who could debug problems in that. The rest of us were ordinary c++ coders.
Comment by Patryk27 18 hours ago
I mean, it clearly is better (in certain contexts), see e.g. https://blog.google/security/rust-in-android-move-fast-fix-t...
> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
Comment by ottavio 17 hours ago
If you really think that switching language is the main driver to get safe programs, the you are on the list of people replaceable by LLMs.
Othewise you have to understand that architettural chioces, concurrency, (weak) cryptographic function and user stupidity have a significant impact, no matter what language you use. Memory management is just a part of the problem.
Comment by Patryk27 16 hours ago
I didn't write that.
> [...] the you are on the list of people replaceable by LLMs.
lol, love a high quality discussion
> Memory management is just a part of the problem.
Sure, then using Rust is a step forward, because that's one less thing you have to worry about. Seat belts don't save all people, but a car equipped with seat belts is - on average - safer than a car without seat belts.
Comment by pelasaco 15 hours ago
Comment by saidnooneever 18 hours ago
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 -_-)
Comment by johnisgood 17 hours ago
Comment by mapcars 12 hours ago
Comment by berkes 15 hours ago
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.
Comment by gspr 15 hours ago
> few/shallow dependencies
is just flat-out wrong. There's (sadly) a big culture of sprawling, deep dependencies in the Rust community. There are of course many counterexamples too, but it's definitely not correct that Rust signals the virtue you refer to.
(Incidentally, the misguided idea among some that as long as a dependency isn't through FFI, it doesn't count as a dependency, is one of the things I dislike the most about Rust culture. That, and pervasive bundling.)
Comment by dbdr 14 hours ago
I have not heard that idea a single time. There's definitely the idea that FFI dependencies "count more" / add more baggage (because there's a bigger risk that the build fails, it's harder to investigate memory safety, ...). Absolutely not that a non-FFI dependency "does not count".
Comment by gspr 6 hours ago
Comment by monster_truck 11 hours ago
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 :\
Comment by zellyn 19 hours ago
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)
Comment by Perz1val 16 hours ago
So called "The vibe". And the vibe emanating from Rust is sometimes unbearable. Like claiming the main feature of the project is that it's written in Rust.
Comment by rvz 20 hours ago
> 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.
Comment by jm4 19 hours ago
Comment by CobrastanJorji 18 hours ago
Comment by scared_together 16 hours ago
In comparison CodeBerg [1] and SourceHut [2] both offer Git hosting but don't merely describe themselves as "GitHub but X".
Comment by thayne 15 hours ago
Comment by CobrastanJorji 8 hours ago
Comment by ClikeX 16 hours ago
Comment by kfrane 16 hours ago
Comment by up2isomorphism 7 hours ago
Comment by chrishare 20 hours ago
Comment by AbuAssar 13 hours ago
Comment by epolanski 17 hours ago
/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.
Comment by nicce 15 hours ago
Comment by adamnemecek 20 hours ago
Comment by taintlord22 11 hours ago
Comment by bogota 19 hours ago
Comment by yashasolutions 21 hours ago
Comment by thiht 15 hours ago
Comment by dainank 15 hours ago
Comment by thiht 14 hours ago
On mobile I literally refreshed the page because I thought my wi-fi broke... Maybe it looks a bit better on desktop
Comment by graypegg 1 day ago
If I could make one suggestion, I really like the old MacOS "inspector" pattern. Basically a consistent way to get meta-information about any "thing" the user chooses to inspect. Your right sidebar is going towards that, but it would need some work to make it more consistent between views.
GitHub's UI has these weird meta-states/restrictions that are so badly explained in the UI they feel like bugs. Each line gets a [...] menu in github which lets you see the blame/spawn a issue linking to it/get a permalink/etc. It's a totally different UI in the diff view, and then totally different again if you're looking at a comment referencing a line in a diff AND different if it's referencing a permalink to a line in a file, even if it's the same code that would be in that diff!
I want the UI to have obvious "nouns". If the UI is showing me a line of code, even if it's in a diff view, let me "inspect" it and get the exact same meta-info + tools I get for lines of code anywhere. It's "a line", not a weird meta state of "a line, but you're in the comment of a PR linking to this line".
Same concept applies to comments/commits/authors/etc. If the UI shows me a username, I should be able to pull up a "who is that again" inspector. Going into github's commit view, clicking on a name... and being sent to a filtered list of that person's commits makes zero sense to me because this is the ONLY place where that happens. That behaviour should be a "recent commits" button inside some "user inspector".
Comment by baepaul 1 day ago
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.
Comment by jillesvangurp 11 hours ago
The value of Github is not just hosting projects and issue tracking but the notion that it's probably the largest professional network of developers that can interact with each other, create pull requests and issues on each other's projects, etc. There are many GH alternatives but very few with the same global network of essentially almost every developer out there.
Instead of everybody creating new accounts on each other's not quite Github clones with only a handful of users, why not improve on the state of the art here and allow people to use their user account from a server of their choice and create a proper alternative to Github?
Comment by benrutter 5 hours ago
I really hope it works out, would bring so many benefits.
Comment by InsideOutSanta 15 hours ago
The UI is a bit odd at first, and there are obvious things that need to be fixed (like the invisible input fields), but by the time I had created an account, I'd gotten used to it, and I appreciate how incredibly fast it is.
I'm a bit worried about this:
> How does gitdot make money? > We don't. > We are fortunate enough to have raised a small pre-seed > round from investors (...)
I'd rather know now how you're making money than find out in three years when I'm invested in the platform.
Comment by garbagepatch 1 day ago
Comment by baepaul 1 day ago
i will also say on accessibility, i recognize the site is a bit too small font in general — and will fix it soon.
Comment by nine_k 1 day ago
Comment by hresvelgr 10 hours ago
I have spent a considerable amount of time learning git, not because I wanted to, but because someone else in my team didn't and inevitably t-boned our repository with a proverbial freight train running commands they didn't understand. It is absolutely unacceptable for a program designed EXACTLY for the purpose of maintaining a history and backup of the evolution of a program to be so unwieldy and occasionally dangerous to use. We can absolutely do better than Git.
Comment by leetrout 10 hours ago
Comment by hresvelgr 9 hours ago
Comment by moistoreos 10 hours ago
Comment by mirzap 10 hours ago
Comment by mgianluc 14 hours ago
Personally I dont care if it is written in Rust or anything else. What I do care is stability, security and features.
I would have enhanced the dashboard a little bit. I understand most of the work was done in the backend. But dashboard is what folks see first. and might lead someone incorrectly judging the work just by looking at that.
Comment by trwhite 14 hours ago
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.
Comment by devsda 14 hours ago
Pre LLMs it did matter, not rust specifically but the language itself. It meant the difference between asking the developer for a feature/fix and getting it done myself if needed.
Now not so much with LLMs, but it does signal something about the development, deployment and supply chain risks involved.
Comment by alexpadula 20 hours ago
Comment by badsectoracula 16 hours ago
That said, from a UX perspective, personally i prefer Forgejo - which isn't that much slower either (judging from Codeberg, it isn't instant but it is fast enough to feel "fast").
Comment by skrtskrt 1 day ago
Comment by 382hi 1 day ago
Comment by gerardojbaez 20 hours ago
Comment by chaz6 1 hour ago
Comment by nullbio 15 hours ago
Comment by arecsu 3 hours ago
Comment by anticorporate 11 hours ago
Comment by virajk_31 13 hours ago
Comment by eqvinox 1 day ago
Comment by baepaul 1 day ago
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
Comment by eqvinox 1 day ago
Comment by baepaul 1 day ago
i think the honest answer here is autonomy. the freedom to choose our own tech stack, our own product priorities, and our own design.
i'll also admit that i don't know forgejo's own priorities as well as i do our own, and that is negligence that we're due to correct. maybe they are perfectly aligned and it does make sense for us to join forces.
but just as with any FOSS project, they have the freedom to choose what they work on as do we, and i intend on respecting that.
Comment by KolmogorovComp 1 day ago
I think the question is why not try to make the other FOSS forges better instead of reinventing the wheel.
Comment by esafak 19 hours ago
Comment by minraws 13 hours ago
Comment by cetinsert 15 hours ago
Nothing that claimed to be a better GitHub was even GitHub enough to begin with.
GitFar an internal a drop-in replacement for our devs to just change the hostname and keep using exactly the same APIs with exactly the same request and response shapes with extensions delivered through request and response headers!
Comment by maxloh 15 hours ago
Comment by Qhemlomo 15 hours ago
Kinda ironic isn't it?
Comment by TazeTSchnitzel 1 day ago
Comment by baepaul 1 day ago
glad to hear the positive feedback :)
Comment by worldsayshi 1 day ago
Comment by baepaul 1 day ago
Comment by Sailemi 1 day ago
Comment by valcker 8 hours ago
However, I think the value proposition should be much higher than simply "GitHub in Rust". GitHub is still a great, complex product, despite its recent problems. There should be some sort of x10 (or at least x5) improvement that will make people _consider_ migrating.
Comment by CodeCompost 10 hours ago
Comment by gr__or 15 hours ago
- no more silo-ing, moat BS, by design - they are working on vouching which is becoming more important in the age of AI PRs
Comment by abathologist 1 day ago
Comment by Imustaskforhelp 19 hours ago
Comment by itsafarqueue 18 hours ago
Comment by applfanboysbgon 1 day ago
Comment by spiralcoaster 23 hours ago
> 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 ! ! ! !
Comment by OsrsNeedsf2P 23 hours ago
Comment by sbarre 22 hours ago
Comment by reactordev 1 day ago
Comment by applfanboysbgon 1 day ago
Comment by reactordev 1 day ago
Comment by Grimblewald 1 day ago
we can see one big initial push, not too suspect. Then a few superficial updates, and then nothing for months.
Unfinished, broken, and ostentiably abandond due to being an unmaintaible nightmare as vibeslop tends to be.
Comment by sieabahlpark 22 hours ago
Comment by johnfn 23 hours ago
Comment by applfanboysbgon 23 hours ago
Comment by johnfn 21 hours ago
Comment by flexagoon 1 day ago
Comment by alienbaby 1 day ago
Comment by baepaul 1 day ago
the overall reason why we didn't ship a mobile site is that code is inherently very hard to read on mobile
and i think to do that properly, you have to design explicitly for it. (and that is not, in fact, something that i do want to vibe code)
Comment by nine_k 1 day ago
Comment by quuxplusone 1 day ago
In the same category: websites that display nothing but a splash screen "This site requires Internet Explorer X" or whatever. Don't nanny me, just feed my browser the HTML! Whether my browser can render it properly is my problem, not yours.
Comment by stared 13 hours ago
Aspecially as now adding responsive mobile takes 15 min (or less).
Comment by Cieric 1 day ago
Comment by baepaul 1 day ago
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.
Comment by Cieric 1 day ago
If anything since the keyboard shortcut already exists, you could always put it in little cursor menu at the bottom of the screen. But yeah up to you, I look forward to your progress.
Comment by mbreese 1 day ago
But, I wanted to say thanks for posting this and being really open in the comments. It’s hard to get so much feedback so quickly. It’s a firehouse of criticism that’s hard to deal with.
You’re handling it well.
Comment by baepaul 1 day ago
thank you for the empathy.
Comment by wjsekfghks 1 day ago
Comment by jacques_chester 1 day ago
IMO a team like yours can either:
* Use LLMs, in which case you aren't "anti-AI".
* Not use LLMs currently, but the non-use is not due to following a principle, in which case you aren't "anti-AI".
* Not use LLMs and promise never to do so.
I'm happy you are trying something new. But you hurt yourself by engaging in something very old: disingenuity.
(edits for presentation and grammar)
Comment by dang 1 day ago
Comment by baepaul 1 day ago
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.
Comment by hyhmrright 8 hours ago
Comment by zemnl 8 hours ago
Comment by applfanboysbgon 1 day ago
https://git-scm.com/about/trademark
> [...] you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service.
> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.
You might've known that if you hadn't vibe-launched this while for some reason marketing it as anti-AI, but here we are in a world where basic research is a dead art.
Comment by clickety_clack 1 day ago
Comment by baepaul 1 day ago
i will be honest and say that we didn't do our due diligence here (we simply assumed that it would be okay to do so, given the existence of GitHub, GitLab, GitKraken, GitButler, and so forth).
it does look like from digging in: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
that portmanteaus are prohibited by the policy that the Git PLC enforces, which as Jeff notes in his email above, does grant incumbent advantages to grandfathered names (e.g., GitHub, GitLab).
we'll reach out to the conservancy, ask for explicit permission, and if not, rebrand.
Comment by zZorgz 1 day ago
Comment by applfanboysbgon 1 day ago
Comment by clickety_clack 1 day ago
Comment by applfanboysbgon 1 day ago
> For the reasons given the Court finds and concludes that (1) McDonald's is entitled to enforce its family of marks that are characterized by the combination of the prefix "Mc" with a generic word; (2) the name McSleep Inn is likely to cause an appreciable number of the public to be confused by believing that McSleep Inn is sponsored, associated, affiliated, connected, or endorsed by McDonald's; and (3) the adoption and use by Quality International of the name McSleep Inn was a deliberate attempt to benefit by the good will and reputation of McDonald's. Therefore, the Court will find trademark infringement, unfair competition, and dilution under the Illinois statute (Ill.Rev.Stat. Ch. 140, § 22).
https://law.justia.com/cases/federal/district-courts/FSupp/6...
I suppose it's not surprising that Europe is less favorable to frivolous trademark claims made by American corporations than America is.
Comment by pdimitar 1 day ago
But you are squinting really hard if you equate "programmers not being good lawyers" with "they obviously vibe-launched the product".
Comment by squeaky-clean 1 day ago
Comment by rfgplk 1 day ago
Comment by applfanboysbgon 1 day ago
Public domain and open source are two completely unrelated concepts. If open source were public domain, you could not license usage of it (MIT, GPL, etc.). What is the point of confidently asserting something you're completely ignorant about as though it were factual?
Comment by latexr 1 day ago
Comment by Kiro 1 day ago
What does anti-AI mean? Don't really see anything about it in the design doc except "no AI copilot".
Comment by baepaul 1 day ago
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.
Comment by sprybear 14 hours ago
Looking forward to seeing even more features, gitdot.
Comment by linobino1 17 hours ago
Comment by sippeangelo 15 hours ago
Comment by screamingninja 1 day ago
> AI.
> We view AI as an implementation detail — and do not think that using it is necessarily good.
> In fact, we think it makes many products worse by acting as a bandaid for poor design.
> That isn’t to say we are blind to it, but that we will be judicious in our use of it instead.
Not sure I follow. What feature are the developers referring to? I understand that AI will power tools that may or may not fit a particular use case. How is AI a feature and what does it mean to be anti-AI?
Comment by 7moritz7 1 day ago
Comment by baepaul 1 day ago
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
Comment by alexpadula 20 hours ago
Comment by ronsor 1 day ago
That sounds more like anti-enshittification.
Comment by trollbridge 1 day ago
Comment by dz0ny 17 hours ago
Comment by kbar13 18 hours ago
Comment by dev_l1x_be 14 hours ago
Comment by skeledrew 1 day ago
Comment by virajk_31 13 hours ago
Comment by 999900000999 23 hours ago
Please don’t do this.
Charge a fair price, in fact find a fair price and double it.
I don’t want a free GitHub clone, I want one that works.
How about 50$
50 private repos, 50GBs of git LFS storage. Add collaborators for free.
Actually respond to customers. At this level you only need 1000 paying customers to make it worth while for 2 developers.
Comment by adrianwaj 23 hours ago
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.
Comment by 999900000999 22 hours ago
Or, if we go a step further you pay a licensing fee for Gitdot and self host it.
The cookie jar of AI training data is very hard to resist even if it’s a non profit
I think 50$ is the minimum you could charge and still have responsive customer support.
Comment by erlau 19 hours ago
I could be wrong but I think besides being able to self host for free you can also pay for something where they help you set it up and stuff
Something nifty also that you can do is that instead of them training on your data they enable you to train your own models on it and download the weights.
Definitely agreed its hard to trust anything you cant audit 100%. I think a non profit structured the right way would probably be pretty trustworthy not to do anything egregious like training on your data though. Or some way maybe to make the thing transparent so you know what happens with the data and you can basically audit the company somehow. I dont know if you would need to go as far as encrypted repos, that seems a little too paranoid but that would be a really interesting idea for a company although the target audience is probably limited
Comment by icase 22 hours ago
Comment by wseqyrku 21 hours ago
Comment by prosunpraiser 19 hours ago
Comment by ramon156 1 day ago
No loading animation, but my screen jitters while loading in stuff. My internet speed is fine, so it's a performance/bug issue.
I also did not initially understand the UI, but that'll come as I use it more
Comment by baepaul 1 day ago
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!
Comment by rashidae 17 hours ago
Comment by john-h-k 12 hours ago
Comment by structwafel 8 hours ago
Comment by HyperL0gi 1 day ago
The first unique characteristic is that it was built in Rust? Why does it matter from a user perspective? I was expecting the first point to be something that would convince me to check it out.
Unless the goal is to find people to collaborate on building the software. I got a bit confused.
Looking good regardless :)
Comment by baepaul 1 day ago
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.
Comment by layer8 1 day ago
Comment by kbelder 1 day ago
At least they aren't using five digit years...
Comment by kbelder 1 day ago
Comment by dstanko 1 day ago
Comment by socalgal2 1 day ago
Me, on an international team, as learned that flawless english sentences as a metric about as silly as dress codes in business. I'll take my california laidback-ness to your stuffy NYC banker rules.
Comment by saghm 21 hours ago
Comment by globalnode 1 day ago
Comment by pitched 1 day ago
What an irony that those exact safety guarantees that made it attractive are now a detriment because they make the project smell like AI.
Comment by gpm 1 day ago
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.
Comment by ecares 1 day ago
Comment by saghm 21 hours ago
You can take these arguments to an unbounded level of depth; someone can be tired of my responses to the responses to so me someone happening to care about something different than them. It's all equally silly, and if you're convinced that your level of depth is reasonable but the others aren't, I'd highly recommend trying to think about why you're so confident that your opinion is important but ones that come after aren't, because it's very unclear to anyone who doesn't already agree with you, and that's usually a sign that there's no point in saying it at all.
Comment by Tepix 16 hours ago
Why rewrite from scratch? Wouldn't it be advantageous to start from an existing forge (there are many these days) and add a new UI?
Comment by whereistejas 16 hours ago
Comment by johntash 18 hours ago
Comment by NetOpWibby 1 day ago
I was gonna call mine EOL and I already bought the domain eol.sh...then again, I could just do mine in TypeScript and launch it anyway.
Comment by OSaMaBiNLoGiN 22 hours ago
Most people would also agree that building a better Github is not a super easy two-person task.
Comment by 1317 11 hours ago
Comment by WesSouza 13 hours ago
Comment by hitoshi1964 18 hours ago
Comment by Lethalman 5 hours ago
Comment by edfletcher_t137 1 day ago
> We don't.
This cannot last forever. What's the plan when it runs out?
Comment by nutifafa 16 hours ago
Comment by 7moritz7 1 day ago
Comment by Ygg2 11 hours ago
Did you check if I name my project 朽木?
Comment by jacobianhessian 19 hours ago
Comment by gerdesj 1 day ago
git itself is decentralised - all repos are equal. Mr T designed it that way because ... well that's all that was needed for Linux kernel development back in the day and it still seems to work. The management stuff can be managed quite well via email and some choice socials. Obviously that nonsense cannot possibly scale to the size of your enterprise thingies!
Yet again we have a better Big Brother than Big Brother ... this time with Rust, yum!
Comment by mckee_plus_plus 1 day ago
Comment by SwiftyBug 1 day ago
I see code reviews is in the roadmap, I can't wait to try it.
Comment by chaoxu 1 day ago
Comment by umanwizard 1 day ago
Comment by baepaul 1 day ago
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.
Comment by garbagepatch 1 day ago
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.
Comment by Aeolun 22 hours ago
Comment by moojacob 1 day ago
Loading files is very slow but I assume that's because HN is hammering the server.
I am not a believer in negative advertising. So I don't give a poop you are anti-ai. Or "better" than Github (better for who??). Just imply you are a code forge thats made for serious developers who need something engineered to be fast and reliable.
I wish you the best of luck, I can see Linear coming out with git repos after coming out with a diff reader. I have a suspicion there's space for many code forges in the market as you build out more features, especially if you lean into your products hacker-y-ness
Comment by dongbinlee 14 hours ago
Comment by selectnull 1 day ago
Hmmm... no. Why should I? Just let me use git.
Comment by hntiz 1 day ago
That said though, one of my pet peeves around browsing Github Web from the terminal was having to click "skip to content" just to get the body. So you definitely delivered there (after having read your design post). Good luck with the rest of the year.
Comment by baepaul 1 day ago
yeah, that admittedly is not priority, but thanks for taking the time to check it out.
Comment by Grimblewald 1 day ago
Comment by syngrog66 1 day ago
I do like that it reinforces this rule of thumb:
Q: "How do you know if any given piece of software is written in Rust?
A: "Oh they'll tell you. They *will* tell you. Upfront and over and over again."Comment by chwzr 1 day ago
Comment by wjsekfghks 1 day ago
Comment by phplovesong 12 hours ago
I bet they will sort it out, and is most likely a top priority.
Comment by purple-leafy 1 day ago
Tell us why we should care outside of the marketing fluff - these aren’t highlights - if anything they are quite off putting.
Your project needs to stand on its own actual merits.
Critique over, congratulations on launching something or building something anyway.
But what makes this different? And why have you chosen that philosophy - outside of marketing fluff
Comment by jurschreuder 18 hours ago
Comment by carterschonwald 1 day ago
Comment by Simon-curtis 1 day ago
You seem to be experienced devs, so I’m sure you already know, but don’t listen to the contrarians on HN. They’ll suck the life out of you because it’s not 100% the way they like it.
Comment by kzdrenka 17 hours ago
Comment by andrewstuart 18 hours ago
It’s like “baby on board” stickers on cars - why are you telling me that?
Then again Rust is so complex maybe it’s worth self congratulations.
Comment by j3s 23 hours ago
lol. really stretching the word "better"
Comment by Uptrenda 21 hours ago
Comment by ericyd 12 hours ago
Comment by philipwhiuk 11 hours ago
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.
Comment by sigmonsays 1 day ago
Comment by Imustaskforhelp 1 day ago
I was thinking about creating my own git forge given the unreliability of Github and I wouldn't be able to create just at the moment incredibly reliable software like git forge although I could use AI to create a minimalist piece of software, I didn't because I didn't want to create yet another AI slop fighting another AI slop (github/gitlab).
Forejo is incredible but I have always wanted to get more alternatives in this field.
Much thanks for making it. I have signed up and I have high hopes for it too and I will try to either self host this on my servers or gitdot.io as well as Github
I recommend making a small community in matrix (preferred), fluxer.gg, discord etc. as I'd like to join it.
PS: small personal thing that I have made which helps in making communities: https://mirror.forum
I am definitely interested in gitdot.io! This seems incredible
I wish nothing but the best for you folks. Gonna create a local copy of the source code of gitdot.io right now!
Thanks for open-sourcing the efforts too. I really appreciate it :-D The software is so nice!
I genuinely hope that you guys and the project blows up and if you guys might ever hire a junior dev, I hope you all could remember me as the world right now needed such software that you have made!! :-D (Although I am more interested in managing servers/golang but that's because rust is hard to learn as a beginner but that's different topic but I like rust's ideas too and rust is a great/preferred language with golang for this type of service :-D)
Comment by wjsekfghks 1 day ago
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.
Comment by mathisdev7 1 day ago
Comment by tadfisher 1 day ago
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...
Comment by baepaul 1 day ago
i think i will get rid of the change on hover, it is a distraction and perhaps was just my ambition to show people how fast we load.
edit: fixed
Comment by wjsekfghks 1 day ago
Comment by isatty 1 day ago
Personally while I appreciate something not being AI slop, writing something in Rust has no meaning to me.
Comment by baepaul 1 day ago
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.
Comment by daishi55 1 day ago
> mobile support to come
Cmon lol. Give opus 20min and it will give you a mobile site throw in a better-looking desktop site for fun.
Comment by dcreater 17 hours ago
If you're sell is being an unenshittified alternative to github, just give it time
Comment by thrownaway561 11 hours ago
Personally if I wanted to leave Github, I would just move over to Gitlab.
Comment by triyambakam 1 day ago
Comment by domtron_vox 1 day ago
If I'm not mistaken about that, you should remedy that to ensure email providers don't dump your emails to spam.
Comment by wjsekfghks 1 day ago
Comment by Grimblewald 1 day ago
The software was never the moat. The skills and experience crystalised within it was, and remains, the product.
Comment by keyle 1 day ago
Common man, you're not even 5% of a Github replacement. Don't act like one. You've built a Git web UI with accounts, the easy part.
> Building software is still hard
You don't say.
Comment by dang 21 hours ago
"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.
Comment by alexpadula 20 hours ago
Comment by dang 19 hours ago
Comment by keyle 18 hours ago
However there is justice for commenting poorly, there doesn't seem to be justice for posting lies and deceit, which is borderline a serial case here(?).
Comment by dang 7 hours ago
We can answer the question by rephrasing it. I would put it this way: "is it ok to be wrong on HN"? The key change is to replace charged words like "lies" and "deceit" with the neutral word "wrong".
People do lie and deceive, but to tell that apart from just plain being-wrong requires knowing someone's intent, and this is not something that moderators (or readers in general) can do. Even courts of law have a hard time doing that! HN comments don't contain nearly enough information to decide it. You would have to have a mind reader [1].
Worse, readers are far too quick to assume lies, deceit, etc., in other commenters that they happen to dislike or disagree with. The internet is rife with this, as we all know. Most of these insinuations are imaginary—we are all too inclined to attribute disingenuousness to the other side. One can easily see this by looking at how the same accusations are made against one's own side.
Once the question has been rephrased in this way, it answers itself: of course it's ok to be wrong on HN. How could it not be? Most of us are mostly wrong about most things. Moreover, being wrong is part of eventually getting something right. Curious conversation, which HN exists for, often involves mistakes, and sometimes the mistakes (or seeming mistakes) turn out to be creative.
Even if we decided it was not ok to be wrong, how would we enforce that? We don't have a truth meter [2].
As we have neither a mind reader nor a truth meter, we can't base moderation on anything that requires knowing people's intent or knowing the truth about things. We need criteria that can be decided from people's observable behavior on the site. As I sometimes put it, we can only moderate by effects [3].
That's why HN's guidelines are they way they are (https://news.ycombinator.com/newsguidelines.html) - there's nothing in there which requires us to know what someone's intent is, nor whether they are right or wrong on a topic. At least I hope there isn't!
What about the truth, then - do we care about it at all? Of course we do. It's critical! But working out what's true vs. what's false is the province of the community, not the mods. It's the commenters' job to do that, e.g. by answering bad arguments with better ones and false information with true. And they should do this within the site guidelines, e.g. by being respectful and curious rather than aggressive and accusatory.
The moderators' job is to hold the container for this or (if you like) to keep the playing field fair. This isn't possible in any complete way - there are far too many factors pushing things into messy, unsatisfying places. But we do what we can.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Comment by bwfan123 8 hours ago
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.
Comment by sspoisk 14 hours ago
Comment by igorusovich89 11 hours ago
Comment by guesswho_ 17 hours ago
Comment by denysvitali 1 day ago
In 2026 not being mobile first is a bit of a disappointment to be honest