Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 440 posts

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#261

Post by n42 »

distortedsignal wrote: post #251
myfonj wrote: post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

I was thinking about trying this out, but there are some reasons why I don't think it's feasible. Where are your comments stored? What happens when you need to run out in the middle of a fire and you don't have time to make your code compile-able? How do you commit "un-compile-able" changes? I think there are some really compelling reasons to try AST-checkin - all your loops can now be changed to functional, dialect…

these are both already solved issues that IDEs deal with with red-green trees

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#263

Post by dmazzoni »

calderwoodra wrote: post #190

The world needs a git alternative. Anyone who has used mercurial at Google or Facebook knows the tooling could be much better. As soon as you have 2-3 people committing to the same repo daily, git falls apart fast. The biggest difficulties with git are merging and branch rebasing. If git could do rebases better, I would suspect software development teams to universally move about 20% faster.

I've worked on projects with thousands of developers committing to the same repo daily.

Git is far from perfect, but in my experience it's been far superior to any of the alternatives I used before it (cvs, svn, p4).

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#264

Post by withinboredom »

oblio wrote: post #237
withinboredom wrote: post #235

Earlier quoted context omitted.

Learn your tools or one day you’ll lose a finger, or worse, your life. — high school shop class

Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.

If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms.

Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill and rote memorization). Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#265

Post by dmazzoni »

sasham wrote: post #52
jsnell wrote: post #27

Earlier quoted context omitted.

And nobody on the team had a reasonably fresh checkout of the repo on their local machine? To put it bluntly, this story does not sound credible. It's also one of the first things you say in the pitch, which taints everything you write later. I would suggest focusing on what you do well, not in making up stories about data loss with what you perceive as the competition. (It's especially odd when Git isn't the obvious…

Swear to god, the story is true! We were able to restore most of the work because someone didn't pull the updates. (I should have added it in the story, didn't think it was important) But it was nerve wracking :')

But if someone DID pull the update, the old commits would have still been in their local repo and they could have run "git reflog" to retrieve them.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#266

Post by oblio »

philsnow wrote: post #248
oblio wrote: post #116

Earlier quoted context omitted.

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (pr…

> peanut gallery of git experts There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies. Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonethel…

I see 2 huge barriers for a new commercial VCS:

1. Devs don't like to pay for core tools. And VCSes need network effects.

2. VCSes seem to be really hard.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#268

Post by oblio »

withinboredom wrote: post #264
oblio wrote: post #237

Earlier quoted context omitted.

Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.

If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms. Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill…

> Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.

Like all simplifications, this is false. If all you do for years after is commit, push, merge, you'll forget.

Especially since you'll need those brain cells to learn the new CPU/GPU architecture, the new JavaScript framework, the new corporate security policy, the docs from your internal architecture team, etc.

Nobody's life revolves around intricate VCS details.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#269

Post by mbreese »

funcDropShadow wrote: post #132
NateEag wrote: post #76

Earlier quoted context omitted.

And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from. Doesn't say a lot for git's usability.

They used --force which is usually the flag to say: Here there be dragon. Be careful.

Yeah, I can’t see how use of a —-force flag by people who didn’t know what they were doing is enough of a reason to switch to a different VCS (let alone write one). The issue was people using a tool in a way that they shouldn’t have. Which isn’t a technical problem, but a training problem. You can’t fix people problems with technology, so I’m sure there will be other footguns in this new system that someone else will figure out how to almost lose data.

Git is great in that it is flexible and powerful. But that power leaves some tools open to people who don’t know what they are doing… that’s the trade off.

(Now something that better handles non-code assets and large data files, I’d be much more willing to listen to that pitch.)

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#270

Post by ajross »

myfonj wrote: post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

> I know it might seem unhinged at first

Not "unhinged". Most kids these days get their first introduction to computer programming using of of the many "block coding" environments, almost all of which are straightforward recapitulations of Javascript under the hood. And it works, and it avoids the problem of having to teach them how to deal with syntax errors before you teach them imperative logic.

The reason people don't do this is that it's just a bad idea. The fact that all source code is stored in a universally understood data format with pervasive support across decades of tools is a feature and not a bug. How do you grep your AST to see if it's using some old API that needs to be refactored? Surely you'll answer that you use your fancy AST grep tool, which is not grep, and thus works differently for every environment. Basically every environment now has to have its own special editor, grep, diff, merge, etc... Even things like documentation generation and source control rely on files being text. And you're throwing all that out just to be different.

Also, FWIW: it's optimizing the wrong part of the problem anyway. The total cost to an organization that develops and deploys software of any form is overwhelmingly dominated by tasks like debugging and documentation and integration. The time spent actually typing correctly-formatted text into your editor is a vanishingly small fraction of software development, and really that's all this helps.

Post reply on HN