Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I’ve read the book on it, and I disagree. It’s certainly its own platform and you’ll have to deal with its ups and downs and learn its DSL.

View on HN

I mean, I read the codebase, which is why I'm saying it's small and easily understood. Sure, it has some specific things to know, and some ("magical") helpers like automatic view functions. But it's no more its own platform than any other micro-framework.

I'd be interested to know what you believe the ups and downs are, aside from speed.

Criticizing Phoenix for being the Rails of the Elixir ecosystem is particularly ironic given Phoenix's creation and design was heavily motivated by incorporating the lessons from Rails' successes and failures.

What are the failures Phoenix addressed from rails?

Phoenix has less 'magic', for one. While it sometimes does mean there's a bit more boilerplate, I think it strikes a nice balance, and the 1.4 actually removed some magic.

Another one is the ORM, Ecto. It sticks much closer to SQL and I strongly prefer it over ActiveRecord. Ecto also includes the concept of changesets, which is a wonderful way to deal with validating user data and definitely an improvement over the Rails approach.

And finally, while I wouldn't necessary call it a 'failure' on Rails' part, the channels functionality in Phoenix is awesome for the more real-time apps that we have these days, and Phoenix is generally quite a bit faster in general than Rails.

The only way Elixir resembles Ruby is the syntax. Everything else is totally different.

The similarities are exclusively because of the do..end

Beyond that there's barely any resemblance.

The optional parenthesis syntax is pretty similar and arguably a bit unfortunate, though wider adoption of the code formatter seems to largely correct this. It's nice in the console to type a bit less, but I can't imagine the utility of this in code that any other person is going to read.

Often times when writing a macro or a function that should appear as though it's a part of a DSL, the advantage of turning off parenthesis can shine here. That's why parenthesis are optional with a lot of the Ecto macros.

I agree. As an additional point, when you have auto-formatting on save, this can also enrich your insight about the DSL at hand. It has for me.

Optional parentheses are pretty much a requirement considering how much of Elixir is actually 'just' macros. I'm very happy that the formatter adds them for me as much as possible though, because I'm also not a fan of how far Ruby takes it.

Agreed. I used to remove parenthesis as often as possible. Looking back at the code, that may not have been the brightest idea.

I really do like the coding convention though that lack of parenthesis can indicate a function meant to be a part of a DSL.

As a long-time Emacs user recently I finally bit the bullet and started working with VSCode (with vscode-elixir and ElixirLS installed).

...Gods, what a relief. Especially the automatic formatting on save is just a lifesaver. At certain point I would not mind if there is one formal syntax enforced like Go does.

Ecto is practically the only library I use where I don't pay attention to parentheses. And the formatter has me covered afterwards.

I was amazed to see how VSCode will suggest typespecs all over the place!

Reply on news.ycombinator.com