No mobile version, but I'm visiting from a tablet, should work at least if switch to "Desktop" in the browser manually. I don't care if I get horizontal scroll - not showing your visitors anything at all is an automatic "I'm out".

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.

I have to agree with the proposition that if you are aiming for the performant, no frills deal - and the aesthetic certainly telegraphs this - you really do not need client-side render, nor overengineered frontend frameworks like React & friends. Ditto for Styled Components (looks like you're not using the latter).

I agree. I like the website, looks minimal, but minimalism is not reflected in the stack.

The look only seems minimal as well. I need to zoom in to read, which eventually destroys the layout. A minimal website has at least basic accessibility by default, this uses some kind of "modern" styling stuff to ruin it.

Yeah, seems like everything just seems minimal, but not actually is.

absolutely this, and I feel the same way about finding it unappealing due to the inconsistency between their "talk" and their "walk". If you preach minimalism but use React or anything similar, you've lost the plot and don't understand what minimalism is at all.

Please, stop using "written in Rust" as some kind of advantage or killer feature.

From what I can see, it would be more accurate if they wrote "slopped by LLMs" :-)

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.

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

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.

If the design was done with Claude Code/Design it would be a lot better than this imo. Bland, but better.

No, it is an advantage.

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.

"single binary, no dependencies besides crypto" would be an advantage, "written in Rust" tells nothing, except (successfully) trying to clickbait

There is no lie or misleading information about rust in the title so it’s clearly not clickbait.

That’s exactly what clickbait means:

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.

https://en.wikipedia.org/wiki/Clickbait

It expresses the exact same thing you've just said and more with fewer words.

The benefit is the static compilation.

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.

You can write git in any language, I don't see an advantage doing it in Rust besides the community and potential of promotion to that community.

You can write any program in any language, but there are definitely benefits of using some languages for some programs. If you disagree with this statement, there's nothing else to discuss, we have irreconcilable differences.

You just responded to a comment giving a specific advantage that applies to Rust and a few other languages which doesn't apply to a large amount of other languages (single static binary).

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?

Sure, but we're talking about a git web UI with a little icing, not a git replacement (at least in most cases). Even so, Rust and Go web projects are much more lighterweight than projects in most other languages, with drastically less effort towards performance, and use less resources as a result, requiring less hardware to operate.

How is statically linked binaries an unique advantage of rust or go? you can do the same with C, C++, pascal, ada, zig, and more. Rust even doesnt do the static binary file by default.

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.

Zig and probably Pascal have the same advantage, can't speak for Ada as I've never built it.

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.

This totally depends.

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.

No, it does not depend. Your parent is correct with his analogy.

Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.

Off: I thought I am becoming dumb, but this really puts me in a new perspective. The odd thing is that even people who work in IT hold similar beliefs. I am not entirely sure what is going on. Favoring a language so blindly seems like a thing, apparently? For example they seem to have convinced themselves that Rust is "safe" if you use it for anything (without implementing the security features) because it is (memory) safe? I did not imagine beginners would make such a mistake either, but alas.

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.

And thus, we all agree that Linux, Windows, and OS X are all bad software, because they're written in C and C++ and have insanely complicated build systems.

Is that even controversial?

You are right that there are many of us who prefer the package manager, there are so many reasons why a package manager makes your life wonderful. Debian has always been a proponent of dynamic linking. When you create a Linux distribution that is a big plus.

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.

If the binary still depends on libc.so.6 (glibc) at runtime, then it is not a fully static binary (read: not a static binary). It is a dynamically linked executable, albeit one where most non-libc dependencies have been statically linked.

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.

That's the default. One can also statically bind that libc.so.6 quite easily. Though that's not the default.

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.

I really was just commenting on the "Only libc is dynamically linked" bit. But yeah, there are cons and pros of dynamic vs static. :)

It is not about being able to make static binaries or really anything that has to do with anything technical. It is more of a cultural thing - the culture in some languages is to link dependencies dynamically (C/C++) whereas the culture in others is to link dependencies statically (Go, not sure about Rust).

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.

I suspect the fact that Github and Gitlab use ruby backends is a significant (although by no means the only) factor in the slowness of Github and Gitlab. So yes, being written in a language that is better suited for high performance at scale is, potentially, an advantage. Although if it is vibe coded, there's a decent chance there are architectural problems that offset the advantage gained from the choice in language.

Reports of Ruby slowness are often exaggerated. Around the time GH was built that was certainly true, but in the ways that matter Ruby is more than fast enough nowadays, even at scale. (Shopify is a rails monolith, as is intercom and a bunch of other massive services) Compute is/was pretty cheap and the economics of ROR mean that it's ultimately not that expensive to run. I think GH's slowness is a mixture of mismanagement and issues on the frontend.

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.

GitHub used to be great when the frontend too was in ruby, the react rework might've got somebody promoted but performance was never the same.

GitHub is so data heavy and there's so little reactivity that it should really be server side rendered.

The frontend was Ruby?? Are you sure?

Not literally. And I would hardly say it was a matter of language superiority. I love Ruby myself. But Github was a lot simpler when it was still just a Rails app.

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/

Yes, standard rails. Rails does not ship with components out of the box and the most prominent component system for rails was built and is maintained by GitHub. They have been moving to React for the last few years though, it seems to be more about hiring and ergonomics rather than capability.

As in rendered server-side.

You assume that its used to show advantage, but we are on a technical forum and for me, as an engineer, its always interesting what language or tech was used to create a project.

Yeah, rust programmers are the new software vegans.

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.

I was very excited about Rust prior to the LLM-era. I never managed to dive deep into it due to the lack of time, but was really planning to.

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.

Feel the same way about the intersection of Rust evangelists and vibe coders. The amount of undeserved arrogance by some hardcore believers is toxic to their culture. I am learning Rust, because there is merit to the language itself, and there are some useful and quality codebases written in it. But it's imperfect in various ways, most of all the evangelists attacking other languages as inferior and unsafe, and the increasingly common massive vibe-coded monstrosities. It's not that I'm against the use of LLMs, I'm against bad engineering practices and unmaintainable code.

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.

Interesting choice when LLMs remove one of the biggest barriers to entry for Rust which is you have to know almost all the rules to reliably make valid changes to Rust programs (which also helps LLMs at inference time when they make mistakes).

What? This doesn't make sense, how is it Rust's fault if people are being lazy and tribal?

It's not the fault of the language itself. But the behaviour gives people bad vibes, and they don't want to associate with the community anymore.

Keep in mind. Learning a language usually also means you interact with the people in the ecosystem at some point.

The community seems normal? Take this popular thread for example:

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.

It's not about if the entire community is weird. But that a few vocal people doing something becomes the first impression of the ecosystem. Which is turning people off from exploring further, as you can see in this thread.

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.

I mean, yeah... but I bet if Zig gets really popular, it will attract similarly toxic weirdoes.

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.

I don't think anyone's disagreeing with you that it's "best", but people are stubborn, irrational beings at heart.

Rust is definitely a hotbed for the kind of smells/red flags I used to associate with C++ Template Demons. "I typed every line myself" ok and?

> If you really think that switching language is the main driver to get safe programs [...]

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.

It would be nice if they mentioned anyhting at all they are doing to implement security features. instead of leaning onf Rust which does absolutely nothing in that regard. just look owasp top 10 and observe it has nothing to do with memory safety. and thats just a top 10 of things.

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 -_-)

Yeah, this is what the people who have parroted "Rust is safe" have achieved. Rust is not "safe" in the broader sense of the word, only "memory safe". You have to implement the security yourself!

"Written in Rust" signals some common attributes.

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.

I'm happy to label myself a Rust fanboy, but

> 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.)

> 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

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".

This drives me nuts too and your comment is justified.

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 :\

Was going to point that out, as it is irrelevant, but I have seen something far worse.

> 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.

It’s one of the first questions people will ask so it’s probably worthwhile to mention it. I didn’t get the impression they did so just because they thought rust was some kind of flex.

If the first thing people ask about your offering is "what programming language did you use when you made this," your offering is probably not that interesting.

The offering in question is "A better GitHub" so you are correct. That is an actual quote from the FAQ [0] by the way.

In comparison CodeBerg [1] and SourceHut [2] both offer Git hosting but don't merely describe themselves as "GitHub but X".

[0] https://gitdot.io/faq

[1] https://codeberg.org/

[2] https://sourcehut.org/

Or maybe your audience is developers who might want to contribute to the project, and would prefer to work in some languages more than others.

Oh stop being silly. Yes, the programming language is technically irrelevant in that they’re all Turing complete.

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)

> but because in 2015, using Go (often) connoted a certain approach, a certain type of engineering, a certain constellation of values

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.

But did you know Rust is memory safe?!

When I see that, my first thought is that there are a bunch of features missing from the original.

It is an advantage

Imagine if someone says, written in in plain and pure JavaScript. Is there a difference? What kind of promise it tells about the software?

You can only do so if it is "written in Zig"

/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.

Interesting. It seems that perhaps a good mental model for solutions like this is to start federating to each other rather than to centralize and create replacement walled gardens. Mastodon style activity feeds might be a good starting point for this.

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?

I see a lot of people trying to capitalize on GitHub's recent failings, and I feel like everyone trying to shoot their shot in this space is missing one key aspect: Git is a terrible TERRIBLE piece of software.

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.

Not asking to be pokey, genuinely curious because I have heard similar from a consistent couple camps... what stack you develop in and what VCS do you prefer?

This sounds like a process + human problem, not a technology problem. To me, it sounds like your team lacks discipline and competence. Sorry bud, going to categorically disagree with your sentiment that git is terrible.

Saying it’s better than GitHub is a bit of a stretch right now, when it doesn’t even support mobile and looks like the stylesheets failed to load

I agree that such a claim is a stretch, however, I personally love the minimalist look (it has its own charm). Saying it 'looks like the stylesheets failed to load' is your own exaggeration.

> Saying it 'looks like the stylesheets failed to load' is your own exaggeration

On mobile I literally refreshed the page because I thought my wi-fi broke... Maybe it looks a bit better on desktop

looks bad on desktop too, most content being uncentered (spread at the edges of the screen).

If I've learned anything about AI recently, it's that AI has just as much trouble centering things consistently as human designers.

I like it a lot.

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.

Interesting stuff! I really like the design philosophy you're applying here, where the browser/web behaviour is actually part of the UX. Pretty rare for web application nowadays!

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".

thank you!

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.

First of all, kudos for the work.

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.

It seems to be a trend of HN lately.

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.

> It just doesn't matter.

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.

I like the terminal aesthetics but please, for accessibility's sake, make input boxes look more like input boxes and buttons look like buttons.

thank you for the feedback, yeah i've been going and trimming a few places where i think my own tendencies have gone a bit too far.

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

I would humbly suggest that a reasonable site should assume that the user has set the comfortable font size in the browser, and make all other font sizes in percentages, or using rem units.

Generally probably shouldn’t try to innovate in too many places at once

we are well aware and duly noted. thank you for the feedback

More vibe-coded trash.

Well, for a more positive comment (since everything seems to be negative - and nobody brought that up) the site is very fast. In fact pretty much everything changes instantly when i click on stuff, which is very rare. The only exception seems to be when looking at some files with a long history (not sure why the history needs to be displayed by default though).

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").

"Better" is a strong word without proven analysis or some kind of statistic, that honestly caught me off-guard as when you state that I expect something like a product like Bitbucket, obviously as you can imagine. Either way, cool project.

A better Github, without 99% of the features that Github has.

I mean, to be fair, a lot of the reason I use Gitea is that I don't want the other 99%.

haha

I built https://GitFar.com to clone my private repos off GitHub and host them without their limits using 100%-GitHub compatible APIs! It is stateless, and only uses system tools like rg and git! Gives me complete freedom which I can truly enjoy pairing it with ZFS subvolumes tuned for the different content types in my repos (text, images, video, etc.)!

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!

Will you open source it?

Love the idea of someone tackling this space in Rust, but please just make a normal UI, I have no idea what I am looking at.

I personally prefer the GitDot UI over the bloated corporate style UIs that all feel the same

Agree!

What's the differentiation against Forgejo going to be?

forgejo is a pretty great piece of software.

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

I'm a bit confused, aren't the Forgejo people trying to build the "best product possible", too? And there's more of them, and they have funding, and… between 2 good forges or 1 great one, I rather have 1 great one… I guess you're not interested in joining them because it's not Rust?

thank you both for asking.

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.

> i think there's a lot of room to make things better

I think the question is why not try to make the other FOSS forges better instead of reinventing the wheel.

Is jj a first class citizen?

I wouldn’t claim boldly„better GitHub” in the tile while having „Mobile support to come”.

Aspecially as now adding responsive mobile takes 15 min (or less).

Tangled (https://tangled.org) is the next social coding platform to believe in imo because

- no more silo-ing, moat BS, by design - they are working on vouching which is becoming more important in the age of AI PRs

No ssh?????? I am fine with everything but this is really but no ssh??? I am out will check back once basic features are here.

no one cares what language the program is written in

What’s that line about vegetarians? Like how do you know if someone’s a vegetarian? They’ll tell you. This, but Rust.

Talking about loading animations etc. and then choosing a hard to read font and font size.

Kinda ironic isn't it?

Big fan of the design! Different but easy to get a hand of. Having /profile also be linked on the homepage with the other main pages for ease of navigation would be nice, the profile link at the bottom feels like it clashes with the rest of the UI to my eyes.

The minimal look feels very refreshing, and yet it's not disorienting like many minimal web git UIs are in my experience; I actually feel like I know how to navigate this thing. Site feels very snappy too, especially with those instantly loading file previews when you hover. Congrats!

thank you! of all things in this launch, i was the most anxious about the design as it is admittedly the most different.

glad to hear the positive feedback :)

It seems like the site is currently getting hugged so I can't look but I'm glad someone is trying to achieve a more minimalistic take on the UX of a software forge. It seems like an area with good room for improvement.

the hn hug is real indeed, hopefully this link is fine. a bit wordy, but goes into quite a lot of the thinking that went into the design: https://gitdot.io/designs/gitdot-designed-by-developers

Developers can champion their preferred language all they want, whether it's Rust, dirt, or grime. What matters to me is having viable alternative platforms and seeing active experimentation with new projects and features.

Looking forward to seeing even more features, gitdot.

The hard part of GitHub is scalability

Would be interested in a comparison with https://sourcehut.org/ (which has a comparable minimal aesthetic, but also has the deep benefit of being FOSS.

Gitdot is FOSS as well from my understanding.

Good work. However minimal doesn't mean better. Nothing wrong in showcasing the work but make sure to add the appropriate description.

Feels weird to ship a website without mobile support in this day. The desktop version looks nice though

Didn't work for me even when I chose to see the desktop site in my mobile browser :/

it is based off a minimum pixel as of now, apologies.

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)

At least it would be reasonable to show a message like "Sorry, no mobile support yet".

As a banner or something, maybe. But I'd much rather see a broken-looking site on mobile than see nothing at all on mobile.

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.

the domain is hard to speak... "git dot io" refers to git.io so you'll have to call it "git dot dot io"

I'd say it's still better than "dotnet"

Seems interesting an I'll take more of a peek after work, but one thing that stood out to me is the only way back to the home page after navigating to a repo is the back button. Going back to the home page via the back button also doesn't retain that "new" was selected. But I agree with others, I do like the simplicity of the site.

this hn thread is interesting as it feels like i'm getting to revisit a lot of decisions i've made in the design haha.

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.

I think I can understand that reasoning. I do have a tendency to explore, especially at the start since it gives me a view of what the site can already do, cause I wouldn't want to run into issues with my own projects without knowing of the possible limitations ahead of time.

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.

I’m not sure I agree with all of your takes either. For example, I’m not anti-AI for coding, so that immediately made me click away. I’m glad I read the comments though because I think the take of “not using your code to train AI” makes a lot more sense.

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.

thank you mbreese, i know folks can be mean and i also recognize where they're coming from (we are certainly far from perfect), but this comment is nice to read.

thank you for the empathy.

you can press "h" to go back to homepage :)

It is ... problematic ... to lead with "anti-AI" and then bury terms like "judicious in our use of it" in the fine print.

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)

I've taken that bit out of the title for the time being, since it was causing confusion.

yeah this has been pointed out a few times, will revise the copytext later but will keep it up for the duration of the post.

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.

I think you're in an interesting space where there's a real opportunity to create something fresh. When people are actively looking for alternatives it will be easier to break out of the established norms.

What does anti-AI mean? Don't really see anything about it in the design doc except "no AI copilot".

thank you kiro! (i feel you may be slightly miffed about the AWS IDE taking your name haha)

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.

Can't import repositories starting with uppercase :?

Did you check if I name my project 朽木?

Fair point is actually “less is les here.” It’s more of an alternative to Gitea than to GitHub, where managing Git is almost an afterthought. Or maybe you haven’t used GitHub recently. But sorry you cannot cal this better GitHub.

This is a violation of Git's trademark, and your usage of it is expressly prohibited by their policy.

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.

I’d love to hear an IP lawyer weigh in on this, because I’ve never heard of this kind of thing before. It doesn’t seem correct that you can use trademark alone like this to extend beyond the actual word used in the trademark. Maybe it’s from licensing or something, ie maybe if a product uses the actual git product, then the git license means you can’t use the name as part of a word.

thank you both for chiming in.

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.

In my opinion (which may be worth little), by using "git" in your product's name today you are also locking onto that technology. So if an another or better VCS comes along (like jj) that you want to embrace it could be harder. (Kind of like how Bitbucket betted wrongly on hg, then later added and switched to git).

Trademark law is ridiculously slanted in favour of existing rightsholders. The most famous example I know of is "McSleep Inn", which was sued by McDonalds and forced to change their name. I think that ruling was complete bullshit, because Mc is so generic and usually a prime factor of trademark law is whether the businesses operate in similar domains, but it goes to show how broad the protections can be. Something like "GitFoo", which is explicitly being used specifically on a site for hosting Git repositories, doesn't stand a chance in hell, and rightfully so because this is actually trying to take advantage of Git's name to market their product.

They might have been sued, but did they change the name just to settle out of court? McDonald’s failed to maintain the trademark on “Big Mac” in Europe when it actually went to a court room https://www.theguardian.com/business/article/2024/jun/05/big...

They did not settle, hence my usage of the wording "ruling" and "forced to change".

> 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.

I mean OK, valid, and they really should get on it.

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

If you look at any other details of this it is very clearly vibecoded.

> Git is open source/public domain. Trademarks don't apply to it.

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?

That’s not right. You can very much apply trademarks to open-source software. See for example Mozilla Firefox. Also, open-source and public domain are not the same thing. Finally, git is GPL.

Nit: the verification code check shouldn't be case sensitive.

"much better" in what way

It is vibe coded in Rust. :)

Interesting design.

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?

The UI is polarising, for sure. But, I will celebrate anyone who takes on the hard task of creating a new code forge. Best of luck!

Does it have a CLI like github? Does it follow GIT? I made an account and did not migrate my repos, as I'd like to test this before moving in... Thanks in advance!

Lookout - next they will rewrite the color blue in Rust and claim advantages.

> 5. What features will gitdot not have?

> 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?

I'm honestly lost for words over how you can write something like this while the web app's source code is clearly heavily integrated with Claude Code.

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

yeah thanks for digging in, this was a bit ambiguous.

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

I don't get that. https://gitdot.io/bkdevs/gitdot/gitdot-api/CLAUDE.md they use agent files in every repo directory for the gitdot code.

That's not really anti-AI. Anti-AI would mean avoiding it as a value regardless of practicality.

That sounds more like anti-enshittification.

I see "anti-AI" in the description and I wonder what that entails. Then I try to look at one of those tending links and all I encounter is "Mobile support to come.", and mobile is my primary device for checking things out. I want to stay positive about the future if this project, but Idk what to think here.

is anyone else absolutely sick of hearing about rust?

Yeah, what I did was reading about it instead, like, on purpose.

fwiw when I opened the site, my fans spun up and firefox slowed a lot. No idea what it's doing, but it's definitely using a ton of cpu.

>As of now, all repositories are free, but we do envision charging for private repositories for teams in the future.

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.

Would you pledge in a crowd-funding campaign to build something like this?

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.

Or full blown encrypted repos where only you have the key.

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.

Oxenai is private but their vcs is open source including the server, so you could self host it for free and use it with other people. The vcs itself is a little bit like git but with native large fial support

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

A lot of fuss that needs to be chiseled out first. There's an idiom that is followed a bit too black and white, but the grey is grey.

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

yeah the site isn't perfect.

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!

> What is a bit unique is: 1) we built it in Rust

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 :)

fair critique. i'll refrain from it in the future.

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.

While we're critiquing, the demographics that I'm part of has trouble taking someone seriously who is too lazy or sloppy to use the Shift key and complete punctutation.

I hate that too, of course, but as long as it doesn't creep into the actual product or website itself, it doesn't really matter.

At least they aren't using five digit years...

And after looking at the site more, I have to say I'm pretty interested. It is a nice-feeling site. There's a few UI oddities that need to have the rough edges sanded off, but I very much like the main approach.

totally agree we should not tollerate lack of shift key use and punctuation

The demographics I'm part of have trouble taking seriously people who yell at kids who live two blocks away when someone from one block away wanders onto the yard the kids are playing in.

I worry that what they’re trying to say is that it was vibe coded but vibe coded in a language with a pretty solid linter.

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

> Unless the goal is to find people to collaborate on building the software.

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.

I am tired of "built in Rust" as an argument, you are spot on, it should not matter. But you are shooting right at Rust culture here haha

And I'm tired of the "tired of 'built in Rust'" arguments because it also shouldn't matter if someone happens to describe their project that you didn't have to go out of your way to talk about in a way that bothers you. But I'm shooting right at the "tired of 'built in Rust'" culture here.

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.

Most people would agree that Github isn't good software anymore.

Most people would also agree that building a better Github is not a super easy two-person task.

Did you guys just make my own git forge plans useless? This looks great!

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.

Congrats on shipping this. Self-hosted + open source is exactly the combination I keep reaching for these days. Out of curiosity, how heavy is it to run — could it run comfortably on an M1 Mac (16GB RAM)?

I honestly do not see the point of all this. it has a font size problem for one, I can't see the edge it's confusing to use.

Github is fine. It just has serious issues with the huge amount of traffic.

I bet they will sort it out, and is most likely a top priority.

The CLI-inspired UI is the most interesting part here.

Nice. Also https://codex-infinity.com can do git hosting but isn’t open source

> 7. How does gitdot make money?

> We don't.

This cannot last forever. What's the plan when it runs out?

Big Brother seems to be built in to us humans.

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!

Paul & Mikkel work at GitHub and are trying to offload traffic from gh

There is a dozen CLAUDE.md in the gitdot source. The "Anti-AI" in your title seems a bit disingenuous.

I absolutely love the minimalist UI.

I see code reviews is in the roadmap, I can't wait to try it.

Feels like one can just copy the UI and use it for forgejo. It would get something similar very quickly, and avoid handling all the difficult stuff I guess.

Ooh, it's the same thing I'm building.

Why does it have to be a website? Why merely "CLI-inspired" and not actually CLIs?

hrm. so i guess if the question is why not just make a software forge that is _only_ based in the CLI, the answer i think is convenience.

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.

Removes a barrier of entry if you can look at it from a browser instead of installing a CLI/TUI.

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.

I love the design. Clean and refreshing - you start at the left and every sub element goes to the right. Like a file browser. And the commit screen is dense but super readable. I would move the summary column from the right of the README to the left of the README on the /home screen (and call /home the /README).

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

> Install gitdot-cli to push and clone private repos

Hmmm... no. Why should I? Just let me use git.

FAQ point 5 is pure comedy.

Just one minor piece of feedback that's unlikely to be a priority. I cannot fully navigate when browsing in a terminal browser (chawan in my case, haven't tried with w3m or lynx). For example the "h" keymap for going home does not work.

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.

oh wow i have not thought about terminal browsers in a while (i used to use one back in the day in college haha).

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

unfortunate name: very similar to Godot at passing glance. my brain already stumbles going back and forth between seeing LLVM and LLM, IP (Internet protocol) and IP (Intellectual property). Don't me started on X vs X vs X vs ...

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."

the design looks neat. + for hexagonal pattern on the backend - that fits perfectly!

thanks!

i want to view desktop on my mobile… and it wont lettt meeeee

It’s weird that “written in Rust” is some sort of headline feature.

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.