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.
I do not find Maven to be an obvious improvement. I would say it's equally bad.
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).
immediate unsubscribe :)
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.
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.
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.
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.
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?
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.
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.
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>]
git switch -c <new-branch> [<start-point>]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)
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.