Please, if you haven’t already started and worked on this, do it as much as you can. Don’t pay too much attention to the "can’t"s of this. If you succeed even in the slightest you’ll have made a much better development environment than most functional languages have.

The statically typed ones are neat because at least they can tell you something about things while you’re coding, but it’s really nothing compared to a Common Lisp or Smalltalk (look to Pharo nowadays, probably). I really don’t like working with dynamic languages anymore because honestly I don’t think they can even be rigorous except when used by robots… With the exception of Smalltalk (and probably Common Lisp) because they’re so incredibly simple, compact, inspectable and interactive.

A running Erlang/Elixir program is a living system, but Smalltalk and Common Lisp go one step further; the program you’re currently working on is a living system. In the case of Smalltalk, so is your editor/IDE. It’s truly a marvel of tooling. If someone said they could offer me a job with Pharo I’d probably try to start next week.

So please just go for it.

Processes have no source code and modules have not necessarily processes.

Modules can call into each other dynamically using apply/*.

But I rarely have to open more than three files at once to work on a certain aspect, whereas one of the files is the one that contains the corresponding test.

Using the fuzzy-finders of my editors (emacs or vscode) is often enough to find the correct file.

And to be honest all those graphical stuff just disturbs me.

Observer is a fine thing to introspect a running system, but nothing I’d like to use to develop in.

While Smalltalk isn’t as mainstream as JavaScript, Java, Python, etc. its history (Smalltalk-71) and influence makes it more maintream than Erlang/Elixir.

Graphical IDE support tends to develop later in the technology adoption life cycle once the technology is more mainstream.

And that makes sense given that there is only so much effort to go around when there is only a relatively small community effort that can be expended on developing the ecosystem - i.e. there is an opportunity cost to developing graphical tools that only becomes worthwhile once a technology acquires a certain critical mass. Before that point is reached, effort is probably better spent on language, deployment and runtime improvements and command line (i.e. scriptable) tooling.

People preferring graphical tools are usually neither in the “innovators”, “early adopters” and possibly not even the “early majority” group - because technologies in those phases tend to be largely supported by command line or text-based tools.

And then there is the whole “Language vs. Tool mavens” thing: Oliver Steele: The IDE Divide (2004-11-21)

I suspect that Elixir is still early enough in it’s life cycle that there are more productive ways to expend community development effort than creating graphical development tools (though in OSS anybody can develop and provide what they want).

it’s difficult to keep the mental model of how everything is connected.

That’s simply a matter of familiarity.

Also there is no guarantee that any particular graphical representation (or interactive model) provided by any tool is in fact a good basis for a mental model - often multiple representations are required to cover all the useful views.

For example, with UML people often provided class hierarchy diagrams because they were easy to provide rather than providing activity and sequence diagrams which actually show how the system works.