12 ms·

I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well. It is essen

by eddd 10y ago

I use phoenix and elixir, I agree with the statement that Elixir is awesome. But don't drink too much cool-aid - Elixir might be dangerous as well. It is essentially a big pile of macros, so sometimes number of keywords that you have to keep in your head is staggering. Also, Elixir is a pretty big language - I knew Erlang before diving into it - so the barrier and number of concepts that you have to get familiar with is huge. Don't get me wrong - all these concepts/design patterns are necessary (I am thinking about BEAM and OTP here). Erlang (and therefore Elixir) is complete as development environment, that's where the amount of knowledge is coming from. Cool intro to erlang/BEAM: http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-and-joxa-oscon-2014 http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-...

yelnatz 10y ago
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.
- Donwangugi 10y ago
  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).
  - eddd 10y ago
    I can recommend: Atom with https://github.com/msaraiva/atom-elixir https://github.com/msaraiva/atom-elixir
- davidw 10y ago
  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.
  - asonge 10y ago
    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.
bitwalker 10y ago
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.
- eddd 10y ago
  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.
paulruby 10y ago
> 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.
- eddd 10y ago
  > Compared to? Perspective matters a lot. That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-and-joxa-oscon-2014 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.
rozap 10y ago
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.

by eddd 10y ago

yelnatz 10y ago

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.

Donwangugi 10y ago
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).
- eddd 10y ago
  I can recommend: Atom with https://github.com/msaraiva/atom-elixir https://github.com/msaraiva/atom-elixir
davidw 10y ago
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.
- asonge 10y ago
  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.

bitwalker 10y ago

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.

eddd 10y ago
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.

paulruby 10y ago

> 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.

eddd 10y ago
> Compared to? Perspective matters a lot. That's why a pasted http://www.slideshare.net/BrianTroutwine1/erlang-lfe-elixir-and-joxa-oscon-2014 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.

rozap 10y ago

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.