Hacker News Reader

Comment by chipdart | Hacker News Reader

> Hi! I created Grace. AMA...

Could you update the project's README.md to say right on the first paragraph objectively what Grace is and what are it's main selling point, followed by a example of Grace's happy path?

The document as it stands just presents a list of vague buzzwords that are irrelevant for a VCS (cloud-native?!) and even after scrolling half way through the doc the reader still has no good clue what he is reading about, let alone why they should bother with Grace.

A paragraph with an objective description would be helpful, followed by a small example presenting Grace's happy path. All the marketingspeak just gets in the way.

View on HN

> irrelevant for a VCS (cloud-native?!)

Disagree. "cloud-native" to me sounds offputting. One of the main selling points for me of git over the likes of SVN is the capability to work offline, in restricted networks and through non-http transports like mail.

And it sounds great to me - knowing that my 99% use case isn’t going to encumbered by one person who insists that we send patches via email

^ this

"Cloud-native", to me, means "built to scale up well". I find that's the connotation that most people associate with it.

Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that.

And, in any team dev situation, you're not getting anywhere until you `git push`, and that requires an internet connection. Assuming ~100% connectivity for devs around the world, in the late 2020's, is the right assumption to make. If offline is a hard requirement, Git isn't going anywhere.

> through non-http transports like mail

yeah, I'm not building a new VCS for that 0.0000001% case.

> Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that.

This doesn't really make any sense. Most people are not "large Git hosters" (and so for them there is no functional difference between "outsourcing Git hosting" and "outsourcing to a Grace hoster that is outsourcing file handling", and even for those who are large Git hosters, they're still going to need a team of sysadm- sorry, "cloud experts" to manage the AWS/Azure/whatever infrastructure.

What actual material benefit is being provided here? It seems to me like it just trades "administrating a standard hosting environment" in for "administrating a vendor-locked hosting environment".

> This doesn't really make any sense. Most people are not "large Git hosters"

I do work for GitHub, so I do know what it takes.

Most people don't run their own Git servers, they use GitHub / GitLab / Azure DevOps / etc. and I intend to create something that's easy for those hosters to adopt.

Grace is also designed to be easily deployable to your local or virtual server environment using Kubernetes - and if you're large enough to want your own version control server, you're already running Kubernetes somewhere - so, party on if you want to do that, but I expect the number of organizations running their own version control servers to be low and shrinking over time.

And Git isn't going anywhere. If that's what you to run on your own server and client, I won't stop you.

Reply on news.ycombinator.com