Hacker News Reader

Comment by 59nadir | Hacker News Reader

> - custom DSL syntax without data representation

This is an interesting comment in a post about Elixir because the Elixir ecosystem is actually full of things that should just be data but are instead macros being used in modules. Phoenix in particular is an especially egregious example of a library that is badly made in almost every regard

> - cosmetic wrappers that are just thin layers without substance

This one is also funny because Elixir itself is little more than a fairly small set of convenience libraries, a syntax and a very good tool for project management (`mix`) on top of Erlang. You can skip the syntax and the convenience libraries for the most part and actually just use Erlang in a `mix` project and get the best of both worlds. The convenience libraries usually are bad makeup on top of Erlang in many cases and you'd be better served just learning the Erlang way anyway.

View on HN

Phoenix is popular partly because people like its API and its convenience macros. It won out over Jose's own framework, Dynamo which he scrapped in favor of becoming a core contributor to Phoenix. Its easy to make yourself sound wise by complaining about macros, but this largely boils down to personal preferences, and a lot of people have different ones from you.

For most of the people who actually use Phoenix, the DSL makes intuitive sense and so there isn't much learning curve, and it is such an important library to applications that use it that its worth taking the time to really learn it, whereas it might not be the case for other libraries that are macro heavy. Most libraries don't go that route though.

I know erlang better than I know elixir but I still prefer to use elixir when I have the choice.

It may be "little more than" convenience, but especially consistency decisions like always data-first functions plus the pipe macro is already a monumental ergonomic leap over erlang. I love erlang but, like php, it is a language where I have to look up the argument order and config options of every function every time I use it.

> Phoenix in particular is an especially egregious example of a library that is badly made in almost every regard

Can you elaborate on this? Why do you think this?

The interface to almost everything either contains or is based on a macro. This persists even in cases where you can clearly see there needed to be no macros at all.

The non-standard (won't work with anything else) and basically superfluous websocket protocol has bad fundamentals and has been marred by bad JavaScript code being needed for it. On top of that it's pretty bloated.

The actual channel processes could've simply followed a standard Erlang interface but someone (...) felt they needed to put their fingerprint on it, I guess, so it kind of doesn't. And yes, again everything surrounding channels is a bunch of macros until you at least get to write and use normal functions in the actual channel module.

They've had a long history of arbitrarily deciding to hide settings/configuration from dependencies they use and having no actual argument for doing so when asked to expose them.

If the part about macros being overused wasn't bad enough Phoenix also promotes this type of thinking by overusing them even in generated code, so people can follow the bad example.

> The interface to almost everything either contains or is based on a macro.

This is not true. The endpoint and router are macro based, but once it is routed, it is all functions. Your controller actions are functions, calling the view/template is a function, your channel is functions, the model/context layer are functions.

When it comes to behaviors, we do our best to follow Erlang/OTP conventions, but deviate where it makes sense. For example, channel has “join” instead of “init” because you can refuse a join but you can’t refuse an init. They have different return types and augmenting init could be confusing if later you were to write a plain GenServer.

It is easy to look from outside and say “someone wanted to put their fingerprints on it” but actual discussions were had in pretty much all of these topics. I suggest asking around. If you asked for something and we had no actual arguments, then please point me to such occurrences. I will be eager to clarify (and as a rule we generally do).

Great reply José, obrigado.

Since you're here, can I ask why Elixir doesn't have an explicit `return` statement? I do miss it sometimes.

Any answers to Jose's reply?

If not, your criticisms seem to hold no water.

Reply on news.ycombinator.com