On top of this suggestion, feel free to ask any, and I mean any Elixir-related question here if you want to talk to an actual person. There are a variety of people carrying a variety of knowledge here who check this site multiple times per day, and many of us are more than happy to answer and discuss topics that have already been answered and discussed to death. Most will even non-judgmentally answer many RTMF-type questions. Don’t get me wrong, we’re human and can be grumpy sometimes, so there’s that, but at least every answer (probably) won’t be prefixed with “Certainly!”

Others seem to have helped with the tooling and easing into learning side of things. There is a lot to learn about the “how” and “why” for OTP, but I’ll try to answer your specific questions as best I can…

Application and Supervisor are modules provided by Elixir’s standard library. Modules don’t need to be imported/required/aliased to reference them or call functions on them. They are available globally within a single namespace.

The use Application bit invokes a compile time macro. It’s a way to inject functions, implement behaviors, generate additional modules, and otherwise minimize boilerplate.

There are some hard rules about what is done at compile time vs runtime, and that guides most of where libraries instruct you to put things.

• config.exs/dev.exs - compile time configuration must go here, e.g. config that’s used as module attributes (like constants)
• runtime.exs - dynamic configuration that’s read from the environment, e.g. the PORT environment variable for a http server
• application.ex - startup functionality and the supervision tree for your specific application. You can define runtime configuration in here if needed, but it’s not conventional

Beyond that it comes down to convention, really. The only way to absorb the style and convention is by looking at more libraries and applications.

Starting with Plug to make a minimal server, ala go, is starting in hard mode compared to using the components provided by a full framework like phoenix. It’s great for learning, but will require you to dig deeper into OTP behaviours than is needed to start building applications.

I’d encourage you to get started with existing libraries to get a feel for how they’re configured and composed, then start building something minimal from OTP primitives once you have your footing.

I would take the time to really learn how the module system works as you’ll find it’s likely more sane than you think. It’s not a huge topic but more than I can type out here, but the docs do a good job.

A few points that may be helpful (that expand on @sorentwo’s answer):

import doesn’t work like it does in many languages. As touched on by @sorentwo, you don’t have to import a module to use it, they are all always available. import is for importing functions (and macros), and only functions (and macros), you cannot import variables or module attributes.

There is no way to magically affect what is available inside a defmodule from the outside. The exception is that every module has an implicit import Kernel which contains such important functions/macros as + and def. This is hard coded into the compiler and there is no way to do this with any other module. If you see just the following:

defmodule A do
  def foo do
    B.foo()
  end
end

B is a top level module, full stop. If it’s not in your project it’s either from a library or it’s builtin.

If you see this:

defmodule B do
  def foo do
    foobar()
  end
end

…that’s a compilation error Without any imports or uses, there is no way to make a random function call like that work.

As you correctly identified, a wrench is thrown into things as soon as you see a use. This means there are macros and therefore metaprogramming at play. It is encouraged to always have a callout block in the documentation to describe what useing your library will do, so usually you can look to the docs to know what’s up.

It’s very important to at least get comfortable with the ideas of macros because from a technical standpoint (not trying to be reductive here, BEAM friends), Elixir’s powerful and well-designed macro system is the thing it’s bringing to the table as a BEAM language. There are other really good reasons to be here like the community, the syntax, and of course the libraries, but a lot of the best libraries and projects are so good because of macros. I’m absolutely not trying to discourage you from getting to know Elixir better, but the cool thing is that if you decide it just isn’t for you, there are other great macro-free BEAM languages like Gleam and, of course, Erlang itself! But I think it’s worth it to stick to Elixir