-11 karma · joined November 5, 2022
The last two words "for me" is what I am talking about. The average web developer doesn't invent new libraries. He uses them.
Elixir reminds me of a poor-man's Haskell. Sure it's intellectually satisfying and elegant and "mathematical/logical", but the reality is that most people are not willing to spend months or years trying to force make their brain work in a different way, when a language like PHP or Python just clicks with how an average person think.
Anyway, what does taking out LiveView change with the harder server deployment or lack of ready-made solutions or big entry barrier problem?
It makes things even less attractive because most of flagship Phoenix/Elixir projects, e.g. LiveBook uses LiveView.
``` iex> length([1, 2, 3]) == length [1, 2, 3] true ```
or (taken from the Elixir docs):
---
Take the following code:
``` if variable? do Call.this() else Call.that() end ```
Now let’s remove the conveniences one by one:
do-end blocks are equivalent to keywords:
`if variable?, do: Call.this(), else: Call.that()` Keyword lists as last argument do not require square brackets, but let’s add them:
`if variable?, [do: Call.this(), else: Call.that()]` Keyword lists are the same as lists of two-element tuples:
`if variable?, [{:do, Call.this()}, {:else, Call.that()}]` Finally, parentheses are optional, but let’s add them:
`if(variable?, [{:do, Call.this()}, {:else, Call.that()}])` That’s it! Those four rules outline the optional syntax available in Elixir. Those rules apply everywhere consistently, regardless of the construct you are invoking. Whenever you have any questions, this quick walk-through has you covered.
---
I don't like this possiblity to use so many syntaxes good, especially if you deal with mulitple parameters in functions. Elixir doesn't have C-like semicolons or braces like in Lisp so multiple parameters are hard to parse sometimes.
The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict and he mentions the optional () e.g. IO.puts "Hello" vs IO.puts("Hello").
I think Phoenix is overhyped a lot. The barrier to entry is gigantic. The lack of up-to-date resources doesn't help. It's definitely not as polished as Laravel for example.
And while there is Pragmatic Studio with their wonderful introduction video, there is nothing like Laracasts where there are new tutorials added all the time. Frankly, it's on another level.
Deploying Phoenix is a nightmare when compared to Laravel.
In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.
Sure try the chat demo apps Phx is famous for but beyond that it's a pain in the ass unless you are very good Elixir programmer and can bug fix and reinvent-the-wheel things out.
Also, Phoenix is bad in environments with bad wi-fi. Think halls, kitchens, factories. So, I wouldn't do a Phx app for some warehouse2customers type of operation a because there are some very interesting out of connection problems, the necessity to constantly ping/"hearbeat" home to the server.
For me it is a pass. The experience with 1.6 and 1.7 rc was bad.
P.S. One extremely important thing, PHP is made for sloppy web programmers (like me). It will forgive and brute-force-work like hell when needed. Elixir is less forgiving and you can shoot yourself in the foot much easier. That's why I prefer PHP - it's much easier to put up some website that works well even on a cheap hardware and then you can PHP-optimize and tinker if you want.
P.S.S. The speed thing is overhyped as well. PHP vs Elixir for web stuff is not as big difference. In Laravel - if you use PHP 8.2 and cache your views, routes, etc. the DB stuff is still the 80% of all of your problems, not the PHP or Laravel.