Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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

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

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

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

  • That's an awesome idea and one that's already being worked on![0]

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

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

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

  • 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.
  • Please, stop using "written in Rust" as some kind of advantage or killer feature.
  • "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.

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

    by rvz
  • 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.

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

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

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

    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

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