I think you would have to first define what is explicitness.

Some could say that managing your own memory is very explicit but I am sure we would collectively agree that we don’t want to allocate memory by hand. Doing so would get in the way of other things, such as your business logic.

Explicitness is not about lacking abstractions. Often those things go together: macros are a high form of abstraction, so we want their use to be explicit.

Explicitness is not about outlining all of the configurations to a function or a library instead of relying on good defaults. It is not against convention over configuration.

Explicitness is about making the choices clear when we believe those choices matter. It is about readability. We use explicitness when we believe omitting information is harmful to the understanding of the software compared to clearly spelling it out.

We will likely agree on many things that need to be explicit but others things will be guided by opinions and/or personal experience.

For me explicitness is not about “not using abstractions”. It’s that the code I use is explicit in what it does (no matter how abstract it is) and it does not do anything I don’t expect. Take elixir macros for example. I don’t need to know how a macro is implemented to have a macro, which is explicit in what it does. E.g. in a project of mine I’m using macros to setup breadcrumb texts/urls. I still need to supply url/title/parent in the macro for a page, which is the things I need to deal with, but how the elements of the breadcrumb are build up and merged is hidden in the macro. Compare that to an implicit calculation from e.g. a module name. There I’m bound to a naming schema or something and can no longer explicitly set e.g. a different parent. I’d consider both “abstract” ways to build up a breadcrumbs list, though.

Also a functional language goes a long way here, as side effects are not littered all over the place to begin with, so the chance for unexpected results is smaller than in oop.

I would say that in general, macros belong to libraries. There are very few cases where I would consider defining a macro in an application.

For libraries my rule of thumb is to first define an interface of only functions and data structures and then evaluate if it needs macros to make it less verbose or nicer to use. The important bit is that macros shouldn’t be the first thing you start with. This leads to a much more flexible design.