The fear about macros in Elixir itself seems a little overblown. Most macros are consumed in the same way you would consume functions or keywords in another language (e.g. defmodule/def/defp/if/unless/etc.). The only one that I can think of that can be problematic is `use`, which is more of a problem with third-party libs where someone might do a lot of "magic", but in general is mostly used to do things like import functions, alias modules, etc. The concern about macro abuse is certainly valid, but I don't feel like it's at all a problem with the core language, but rather abuse by people who feel the need to use macros for things which do not require macros. In addition, macro usage in Elixir is always explicit - you must import/use macros at the top of a module, and the implementation of those macros is easy to find by going to that module definition. It's not nearly as dangerous as say, monkey-patching in Ruby.

In any case, just wanted to chime in with my two-cents. I've been working in Elixir for the last couple of years and have never felt like I've been bitten by macros. Elixir is certainly a bigger language than Erlang, but many of the things Elixir adds on top of Erlang are what make it so pleasant to work with. For example, the reduction in boilerplate for gen_servers which is made possible with `use GenServer` in Elixir.

My concern is not about the macros themselves (I don't want to start war on macros and DSLs here) but the amount of them - especially in phoenix.

Hard to grasps at first - later it is a huge benefit.

> Elixir is a pretty big language

Compared to? Perspective matters a lot. It is definitely bigger than Erlang but I would still classify it as considerably smaller than languages like Scala and C++ and still smaller than Ruby and Python.

> It is essentially a big pile of macros

Since "a big pile of macros" is not quantifiable in anyway, I have decided to check for macros and function definitions in Elixir source and I got 1687 functions and 169 macros throughout the whole standard library. It is roughly 10%.

The Kernel module (imported by default) has 60 functions, 78 macros, which is, for example, considerably smaller than Haskell's prelude (about 300 last time I checked?).

Considering things like `defmodule`, `def`, `defp`, `case`, `&&`, `in` are regular macros in Elixir instead of syntax keywords (as they would be in many languages), I wouldn't personally call it a big pile. Although I agree that's a matter of perspective and that's why I decided to measure it).

> the barrier and number of concepts that you have to get familiar with is huge

I definitely agree with this. There are functional aspects, like pattern matching and immutability, the concurrency aspects and the OTP bits. There is definitely a learning curve although most patterns, as you said, are necessary for building the kind of systems Erlang/Elixir enable you to.

> Compared to? Perspective matters a lot.

That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-... - slide 96 (I can't find a direct link). Elixir sits above golang but way below Java or C++. Maintainers are doing pretty good work at simplifying things as language matures - for example merging Dicts and Maps together.

> I wouldn't personally call it a big pile.

Touche.

I use elixir (and phoenix) as well, and this is my biggest gripe with the language.

When reading (and reviewing) code, sometimes you can't logically follow what's going on since most of the code is hidden behind macros.

It's ok if I'm on my IDE that helps expand macros to quickly check the flow, but when it's on a webpage or in a gist somewhere, you're on your own.

Which IDE do you use? I have been messing around with alchemist on emacs but the learning curve is pretty steep (i'm not an emacs guru).

I can recommend: Atom with https://github.com/msaraiva/atom-elixir

Is this a community/culture issue where you can keep things in check if you make a concerted effort to dissuade people from using something too much?

Sort of like Rails was big on testing, which was generally a win.

Aside from pretty simple `__using__` macros, most Elixir devs come to appreciate macros and then elect not to use them in the most situations. Most people who do use macros have a very small Macro that just returns the AST for a function call after some tiny little adjustments to the arguments is made.

There are a few exceptions where there are very large projects that make heavy use of macros (Phoenix's router, Ecto), but they are by far the exception. Most of the macros you use every day are simple ones.

I don't follow how "these things are macros under the covers" translates to "i need to keep more stuff in my head"

And the argument that "the community discourages macros" isn't particularly compelling, but for whatever reason it has worked well. People seem to use them rarely, and when they are used they're reasonably straight forward. I've been using elixir for a couple years now, and I haven't run into many cases where macros ended up confusing me as a reader.

On the contrary, I stumble over the more esoteric "discouraged by the community" features in scala literally every day.

Relying on the community to exercise restraint with the powerful parts of the language is a huge gamble, but it has worked well in the elixir community.