This a real strength for the Elixir world and something I wish was more common across development contexts. But it isn't perfect either.
The biggest weakness with ExDoc is oddly also one of it's greatest strengths: that the documentation is fairly tightly coupled with the code. Insofar as we're using the documentation as a reference for things like function explanations, this approach (unsurprisingly) works pretty well. But the way we structure our code across applications, modules, and functions for various technical or code quality reasons isn't the best way to build it's documentation.
For example, recently I've been learning the Phoenix Framework. For the framework to be both flexible and also so that the code is well organized, it's been coded across different Elixir projects: there's "phoenix", "phoenix_live_view", "phoenix_html", "phoenix_ecto", (etc). This division is absolutely appropriate, but it does mean that to do anything useful with the Phoenix Framework you're pretty certainly going to use a number of these different Elixir projects. But there's nowhere for the documentation to weave together the master plan of these different modules, the bigger ideas and concepts to exist. The most basic unit of documentation is the individual component and so when a real understanding how the components fit together is needed, there's no obvious place for that to live and often times you end up context switching between different sets of documentation.
Don't read this as ExDoc should account for this, but that it's easy to see ExDoc as the only documentation tool when often times complete documentation of complex projects requires something more.
This is partly the reason why we've built something custom for our documentation (using all of the wonderful tools provided by Elixir) at https://ash-hq.org. We still have a lot of work to do, but it allows us to provide a more wholistic documentation experience over all of our projects.
In all honesty, though, documentation is still a major hassle for people using the framework today. There is a lot to it, and even with a wholistic docs site it can often be hard to find what you want. But with this we at least have a singular vision to build towards, and its grown in leaps & bounds over the last 6-8 months.
The biggest weakness with ExDoc is oddly also one of it's greatest strengths: that the documentation is fairly tightly coupled with the code. Insofar as we're using the documentation as a reference for things like function explanations, this approach (unsurprisingly) works pretty well. But the way we structure our code across applications, modules, and functions for various technical or code quality reasons isn't the best way to build it's documentation.
For example, recently I've been learning the Phoenix Framework. For the framework to be both flexible and also so that the code is well organized, it's been coded across different Elixir projects: there's "phoenix", "phoenix_live_view", "phoenix_html", "phoenix_ecto", (etc). This division is absolutely appropriate, but it does mean that to do anything useful with the Phoenix Framework you're pretty certainly going to use a number of these different Elixir projects. But there's nowhere for the documentation to weave together the master plan of these different modules, the bigger ideas and concepts to exist. The most basic unit of documentation is the individual component and so when a real understanding how the components fit together is needed, there's no obvious place for that to live and often times you end up context switching between different sets of documentation.
Don't read this as ExDoc should account for this, but that it's easy to see ExDoc as the only documentation tool when often times complete documentation of complex projects requires something more.