Comment by alex_lav | Hacker News Reader

Comment by alex_lav | Hacker News Reader

> During my period of intense frustration with Gradle I found this condescending blog post claiming that anyone who dislikes it is simply using it wrong.

Replace Gradle with literally any tech tool and you'll find the same articles. A hill that I'll gladly die on is that Git sucks, maybe more than any other tool so widely adopted, and yet bringing up how badly it sucks usually results in a deluge of downvotes and "No! You don't understand! Just learn the internals of the tool!" and "Oh yeah well if it's so bad, what do you suggest?!"

I reject this sentiment. I don't have to have all the answers to point out that something sucks. I also shouldn't be expected to learn the inner workings of a tool that we expect code school students to use.

> But that’s stupid. When I took a step back I realized that all of the problems I had with Gradle before still existed, I just understood how to use them to get work done. But the fundamental problem with Gradle is that it simply does not justify these complexities.

Yep. Spot on.

> But goddam it feels like there must be an easier way to accomplish this stuff.

I've done multiple forays into Java and always fall into the trap of "Certainly in <insert year> java tooling must not suck as bad?" but I come up empty. It still sucks. A real mess.

I really enjoyed this blog post.

> Replace Gradle with literally any tech tool and you'll find the same articles. A hill that I'll gladly die on is that Git sucks, maybe more than any other tool so widely adopted, and yet bringing up how badly it sucks usually results in a deluge of downvotes and "No! You don't understand! Just learn the internals of the tool!" and "Oh yeah well if it's so bad, what do you suggest?!"

The difference is that Gradle has an obvious better alternative: Maven. The thing that Gradle does better than Maven is that it makes quick hacks easy. But once you try to use Gradle in a "proper" maintainable way, as this article does, you discover that all the things that annoyed you about Maven were there for a reason and you have to essentially reimplement the same things in Gradle. And then, if you have any sense, you go back to Maven.

> The difference is that Gradle has an obvious better alternative: Maven.

I do not find Maven to be an obvious improvement. I would say it's equally bad.

With Maven I can't have a distributed build cache or multi-project caching

Yeah maybe. But I've found cache problems have always ended up costing more time than the cache ever saves.

Yeah, you haven’t worked on projects big enough.

I worked on what was claimed to be the second-biggest scala codebase in the world - 10MLOC, 500 contributors. Of course just switching off caching with 0 other workflow changes doesn't work, but I remain convinced that transparent caching does more harm than good.

>The difference is that Gradle has an obvious better alternative: Maven.

The alternative to Git is Mercurial, though I've never used it so I can't vouch for it. I do think I've read that Git is much faster though, but it's generally accepted that Mercurial's UI is a lot better and more consistent.

AFAICT, all the other alternatives to Git really can't do the same stuff Git does (namely, being distributed).

Fossil is the one to look at.

Yeah, you're right, I didn't want to complicate my post but Mercurial does have a cleaner design. But ultimately they never had an impl that was fast enough to use back when it mattered (maybe they still don't). Speed is a feature, and an important one.

The last time I used maven I found it to be painfully slow in comparison to gradle. Has this improved? I switched to gradle in 2015 and that was a pretty big motivation at the time.

I've used Maven and Gradle since before 2015 and never had that experience. In theory Gradle's caching should make it faster than Maven when it's working right; in practice I found Gradle's slow startup and the number of times I needed to invalidate the caching anyway more than outweighed that benefit. If it's working for you then great.

Curious question: why do you think git sucks? From my perspective is one of the fundamental tools behind modern software engineering. brilliantly designed and yet so simple to use. I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry

Allspice - git platform for hardware engineers

https://www.allspice.io/

> git platform

immediate unsubscribe :)

Mostly the UX is inconsistent. Git Koans [0], which is now 10 years old, still holds mostly true. I do feel it has improved, though not in ways I've bothered to use. `git switch` for example, was introduced at, uh, some point because `checkout` is so overloaded.

Anyway, git was the first and only VCS I ever learned so I don't really see the big deal myself. I didn't learn all the internals super well, but I generally did just learned it. On the same token I've never really heard of a VCS that people don't complain about. Except Mercurial.

[0] https://stevelosh.com/blog/2013/04/git-koans/

> I've never really heard of a VCS that people don't complain about.

Just noting that this is unrelated to a piece of software being good. People complain about tools that're A.) crappy and/or B.) Widely used.

true!

Of the DVCS systems that came out at around the same time (hg, git, and bzr all came out within a month or two of each other), I would probably rate git the worst.

The most notable issue with git is that it's help is... anti-helpful. It is pretty jargon-filled, and there have been numerous moments where reading a help page has left me actively more confused about what a git command is doing.

Of course, part of the reason why the help is so unhelpful is because git's UX is poorly designed. When even the help page has to admit that a command actually does three different things depending on parameters, you know it's bad.

I'll also point out that I've seen far more repository corruption issues with git than I have with any other VCS (and I've used CVS). Accidentally torching your data is quite easy in git, and appreciate the irony of an immutable store of data needing a garbage collector for the data it's storing. Something like Mercurial's changeset evolution and phases is far, far saner for development than working with branches in git.

> appreciate the irony of an immutable store of data needing a garbage collector for the data it's storing

I don't see how this is ironic. Do you also think it's ironic that pure functional programming languages like Haskell are garbage collected?

> appreciate the irony of an immutable store of data needing a garbage collector

You cannot have exclusive immutability without a garbage collector.

Have you ever used a programming language with exclusively immutable data that didn't have garbage collector?

Try implementing one. You'll see.

> why do you think git sucks?

DX is awful. Inconsistent, unnecessarily confusing, obvious and common usability paths aren't straightforward. The simpliest example: why isn't "git undo" a thing?

> From my perspective is one of the fundamental tools behind modern software engineering.

This dogmatism is the root cause behind the lack of improvement. People insist it's already good enough.

> yet so simple to use.

Simple until it's not, which is almost immediately.

> I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry

Few other industries would be so convoluted into thinking such a terrible user experience would be allowable.

For me it’s the fact that everything about it seems to be about making the tool easier for the developers who wrote it to write it rather than making it easier for the people actually using it. It periodically tells me that garbage collection has given up and I need to run a specific git command to make it work again. Why doesn’t it just run it since it knows the command? Also, as a user, is there any benefit to me knowing that garbage collection happens at all? I’ve never had to know or care about that with any other source control tool. Either it didn’t exist, or it worked so well that it never came up.

There’s a bunch of modal-ness (modality?) throughout git. You can’t be explicit about things so it’s extremely easy to make a mistake. I’ve frequently gone to make a branch only to realize I had the wrong parent checked out, so now my branch is branched off the wrong thing. In other systems I could say “<tool name> create branch x from parent y”. In fact, this has happened so frequently in our group at work, that several reminders have gone out to “make sure you branch off the correct branch…”

It handles large files really poorly and requires a 3rd party tool to make it work reasonably. But then if you use lfs or a similar tool, several other 3rd party tools that work with git don’t work.

> In other systems I could say “<tool name> create branch x from parent y”.

While the default of `git branch` is to branch from the commit you have checked out, the command does take an optional argument for the start point of the new branch:

  git branch <new-branch> [<start-point>]

or, to create and check out in one go

  git switch -c <new-branch> [<start-point>]

Thank you! That is very helpful!

Git is an amazing idea that needs a completely revamped UX.

The general complaint is that Git's UI requires you to understand how it works internally to be able to use it (properly).

IMHO Git is fine, and forcing the complexity on the user is not a big deal as Git is simple enough... as long as you forget that submodules ever existed. Git's approach really shows it's problems when you use submodules:

- Want to clone a repo with submodules? Gotta know beforehand to use git clone --recursive, or remember to use git submodule update --init --recursive after cloning.

- Want to pull? Now you have to use git pull --recurse-submodules instead of git pull.

- Want to checkout a branch? Now you have to remember to do git submodule update --recursive after checking it out.

Etcetera. Instead of being handled transparently by Git like they should be now every time you do something in Git you have to remember to do something else to babysit the submodules.

It's complicated to the point that a lot of people come up with their own alternative instead of using submodules (git subtree, git subrepo, etc)

I am just smirking that within seven minutes, the git supporters are appearing.

Git may suck but it suck fast! Alternatives sucks as well but are also slow.

Reply on news.ycombinator.com