Quick summary of my opinion can look like this:
1) dub is a horrible build tool
2) git submodules is a horrible way for dependency management
First thing is something we can improve on in future and,
actually, dub supports using rdmd as a build tool already.
Second thing is an inherent issue that won't change without some
fundamental breaking changes in how hit submodules are
implemented.
Because of that I am trying to push dub despite the fact I don't
like lot of things about it personally.
----------------------------------------
Explaining why dub is a horrible build tool is hardly necessary -
there are plenty of cases in this thread already.
So why git submodules don't really work?
1) Lack of version management
submodule remembers specific commit hash and that is all. As of
recent git version one can also remember remote tracking branch
(but it will still keep specific hash in history!)
This may not seem an issue if you have only few dependencies and
control them all. But it scales badly once bulding the project
needs many incompatible versions of the same dependency and
dependency count increases in general.
2) Lack of local cache
This is really annoying when working with many project with
similar dependencies - those will get cloned over and over again,
taking quite some time. Can possibly be fixed with clever scripts
that replace remotes with local repo paths but that is not
out-of-the box solution
3) Lack of package repository
Biggest thing about dub is not dub tool itself. It is
code.dlang.org and what it can become in future. Providing simple
centralized way to discover new libraries and quickly try those
in uniform matter is the way you build decentralized ecosystem
(ironically).
With git submodules you are pretty much stick with doing GitHub
search over and over again
4) Inherently coupled with specific DVCS
git and GitHub are most common (and officially endorsed) ways of
version control in D world but those are not the only one. dub
registry allows to use GitHub, GitBucket and source tarball
packages in the same project - in simple uniform matter. It is a
100% in-house tool that does no depend on decisions of external
project maintainers that provides a common API for everything
else to interoperate
