Live data from Hacker News

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

gitdot.io

211–220 of 322 posts

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

#211
post #156

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

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…

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

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

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

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

#213
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!

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

#214
post #163

Earlier quoted context omitted.

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.

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.

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

#215

Earlier quoted context omitted.

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.

> They claim it is better just because of the language 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…

I can imagine LLM can, or will be able to, write safe C too. At least safer than people can.

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

#216

Earlier quoted context omitted.

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…

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 arg…

> Rust even doesnt do the static binary file by default.

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.

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

#218
post #216

Earlier quoted context omitted.

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 arg…

> Rust even doesnt do the static binary file by default. 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.

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.

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

#219

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.

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

#220

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…

Will you open source it?
Post reply on HN