Hacker News Reader

Comment by Liberonostrud | Hacker News Reader

If you are an Elixir (or perhaps Clojure) expert, the following doesn't apply. But every other person jumping ship from, for example PHP or JavaScript should think twice.

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.

View on HN

I find this a pretty unconvincing comment, bordering on bad faith. A lot of vaguely defined negatives with no details.

> Deploying Phoenix is a nightmare when compared to Laravel.

It ships with a Dockerfile which is simple to deploy if you know docker at all. How is this a nightmare exactly?

> In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.

Like what? Give examples. I find the ecosystem pretty well developed, actually.

> Also, Phoenix is bad in environments with bad wi-fi.

Do you mean the (optional) liveview, which your preferred framework Laravel is in the process of also implementing with blade/livewire?

Programmed in a reasonably defensive way, Liveview will perform and behave mostly like any SPA application - often better, because there's less front end code to load up front. Of course, in cases where internet access is known in advance to be bad, it should probably not be used. This will be a pretty rare case, though.

> The experience with 1.6 and 1.7 rc was bad

The RC process was long, yes, but how can you fault the framework for this? What could they have done differently? It sounds like you wouldn't be happy either way?

> PHP is made for sloppy web programmers (like me).

I think I know why you didn't have a great experience with Phoenix.

> What a ridiculous comment. Firstly, I am not very inclined to take the advice of anyone using PHP in 2023

If you want your own comment to be taken seriously you should dial back on the bitchiness

You're right, dialled back.

Fwiw, I respect that you took feedback. It's special moments like these that reinforcement my faith in humanity (on the Internet).

I actually found it informative. It gave me a quick overview of the issues with this famous web framework that I would probably not find anywhere else.

> informative [...] of the issues with this famous web framework

The conflation of LiveView with Phoenix web framework is dangerous misinformation. LiveView is just a subset of Phoenix, with very specific trade-offs and unfamiliar programming patterns compared to usual web development. I've found Phoenix to be very productive for regular web programming.

Genuinely curious, but which part was informative of anything other than one users opinion? I'm a huge fan of elixir and found it to be one of the easiest languages[1] I've learned to date, so I'm definitely biased, but I'm struggling to find anything in GP's post that is informative in an objective way (outside of the tutorial thing that presumably posts more content).

I believe I could replace php/laravel with elixir/phoenix in GP's post and be subjectively just as correct in stating my opinion.

[1] the easiest standard library to learn...the OTP library is often treated as a core part of the language and that did take a fair amount of learning before it clicked.

> the OTP library is often treated as a core part of the language and that did take a fair amount of learning before it clicked.

For me, probably the 2 most foreign concepts coming in with a non-functional mindset were GenServers and tail-recursion. They require a shift in mindset about how to handle state and do flow control. These two things would be stumbling blocks to beginners, especially someone who claims to prefer "sloppy" code

tail-recursion is just an implementation detail...but with recursion, I find non-programmers struggle no more with them than simple loops. It's only programmers who develop a strong familiarity with loops that feel some sense of unnecessary friction. Neither are more than code that says "do this thing until this condition is met"

I agree. As I said it’s those programmers coming in from non-functional languages (likely the majority). When you’re conditioned to using for loops with mutation, it can feel strange to use these new patterns. I think comprehensions, map, and reduce are becoming more common in other non-functional languages, so maybe newer programmers would instinctively reach for these first.

genservers aren’t a functional construct and are specific to languages on the ErlangVM/BEAM.

They are more closely related to the Actor Model.

https://courses.cs.ut.ee/MTAT.08.024/2020_spring/uploads/Mai...

Ah yeah sorry, you're right. It was actually the GGP talking about OTP that inspired me to write the comment, but it is actually relevant to the immutable aspect of Elixir (which is something you don't really see outside FP) as GenServer provides a way to keep state via named processes the way someone might use global variables or singletons.

Yes, it is a bit of a ranty comment. Yes, it shares their opinion alone. That is quite clear. And yes, there might be different opinions out there.

But in the midst of their opinion, they raise awareness to a point not much talked in the tutorials or other material I've seen about Phoenix: it might seem easy, but has it's drawbacks. Drawbacks which could be easily avoided by power users, but might not seem obvious to a newcomer. That's it. The rest is description of such drawbacks, from the poster's perspective.

I find this informative because it is information that I haven't seen anywhere else. Not in tutorials, not in presentations, not in any other place I've seen people talking about the subject.

Of course after thinking for a while it becomes obvious that a framework built on such a "different" platform with it's own unique patterns and quirks would of course fit such a description. Any tech could, depending where you're coming from. That's OK. And it is also OK that enthusiasts of any tech would not present themselves in such a harsh way. It's all good.

> they raise awareness to a point not much talked in the tutorials or other material I've seen about Phoenix: it might seem easy, but has it's drawbacks.

That's because that's a statement without value.

Well, as I've stated in all my replies, it was valuable information to me.

> "different" platform with it's own unique patterns and quirks

Much of what OP listed was a criticism directed at LiveView, the 'Live App' functionality, not Phoenix, the web framework. Live Apps are not exclusive to Phoenix either, as there are now imitators for every other web framework now, which at least speaks to its broader appeal amongst developers. So the criticism could be leveled towards the far less mature 'Live App' libraries on PHP/Python/JS/C# and so on and on:

https://github.com/liveviews/liveviews

As for lack of documentation, I find this a strange criticism to level at the Elixir ecosystem. It's documentation tooling is very good, and so libraries are typically very well documented, and often include 'doc tests' which double as both examples of usage and inline unit tests. You can simply launch the REPL (called IEx) and type `h <module>.<name of function>` and get documentation for any function.

As for the language, I think immutability and using GenServers could be a little counter-intuitive to people used to mutating variables inside of loops and using shared singletons, but elixir-lang.org and Exercism provide very approachable learning materials for understanding the language.

Small nitpick, but Livewire is not part of the core Laravel framework; it is a community managed package.

> Phoenix is bad in environments with bad wi-fi

I think people conflate LiveView with Phoenix. I think the former is a little over-hyped, has a high learning curve, has an impedance mismatch with usual web developer tooling and libraries, as well as the latency issues you describe. In the app I'm building I've used it for only part of the functionality. The rest is a plain old SPA and a few templated SSR pages. My other experience lies mainly with Django/C#, but I'd say Phoenix is highly ergonomic for making boring websites, has sensible abstractions for database mapping and date/time, and has integrations with every service I've encountered. I do, however, look forward to making some pure LiveView projects in the future as I gain more experience with it, and it does make sense for realtime collaborative tools where always online is a soft-requirement.

This is what I came to say as well. Phoenix is not LiveView and LiveView is not Phoenix!

And even when LiveView is used, there's no reason whatsoever that you can't still use whatever JS client-side thing you want for things when you need it. There are increasingly more built-in JS functions available that run client-side, and Alpine.js in particular fits neatly into Phoenix and lets you do a ton of stuff. I always add Alpine and use it for menus and other stuff. If the action doesn't need data from the server, I do it client-side in Alpine.

IMHO way too many people think of LiveView as a total replacement for javascript that is all or nothing, but that's a bad approach.

Agreed. I think the OPs criticism of LiveView is also a bit overblown. You have blocking latency issues in CRUD apps too, and in general UI changes pair with data updates, and as you say, where they don't you can still do client-side UI updates.

> Deploying Phoenix is a nightmare when compared to Laravel.

What? These days it even comes with a Dockerfile. Yes, it's harder than copying PHP files, but have you ever administered a server running PHP? These days containers are the de-facto standard for any non-trivial application for a reason.

Containerising PHP on the other hand is a bigger pain, as you need to set up Apache, fpm, php.ini and all the myriad of php libraries, THEN your actual code.

> Phoenix is bad in environments with bad wi-fi

Dude, stop with the misinformation. Phoenix is not Live View, and it's a web framework like any other. Either you're willingly spreading FUD, or you just don't know what you're talking about.

This reminds me of a certain HN user deep into Rails that for a couple of years came to shit in every Elixir thread saying learning it is a waste of time and new developers should be learning Ruby instead.

You have some good points but this is overtly negative.

First deploying nowadays is pretty similar for real world apps: container, dependencies, env vars etc.

But sure if you don't need what the Beam offers there's probably no advantage to use Phoenix over Laravel.

Second, Elixir is faster than PHP 8.2. I should know, I've ported an api from Symfony to Phoenix and ran both versions concurrently on the same server with the same data. As you mention caching, I would say using ETS will actually make your Elixir version even faster compared to using Redis or Memcache.

Lastly, I don't really appreciate and agree with the "forgive and brute-for" and 'made for sloppy web programmer" comment, I think it says more about the way you code than something else.

PHP in strict mode with type hints and tools like PHP Stan is not "sloppy", it's actually better than Elixir in this regard.

The only thing I can agree is deploying, which is pretty daunting compared to Laravel, but still feasible (unless you have the horrible idea of using mnesia, God help you then) but everything else? I have no idea what framework you've bee using.

>Elixir is less forgiving and you can shoot yourself in the foot much easier.

What? If anything it's the other way around. Elixir does not let you shoot yourself in the foot, it will crash and tell you why exactly it crashed. PHP will chug along and you won't even feel pain even though you don't have a leg anymore. That is NOT a good thing.

>unless you have the horrible idea of using mnesia

WhatsApp used (uses?) mnesia, what is the problem with it?

If I recall correctly, if some node desyncs, it's hard to get it started again. You have to manually transfer the entire database from another node which can obviously take a long time if you have a large database. It doesn't really handle netsplits by itself (there's https://github.com/uwiger/unsplit) so you have to be prepared to do this yourself.

Got it, thank you two for the answers.

I had a _really_ bad time using it. I used it for a relatively straightforward application but boy did I regret it.

It's not intuitive at all and configuring it is a PITA. While there are docs, they are as murky as bog water if you're new. Deployment? My god, it had me tearing my hair out and I should have just ditched it all right then and there. Migration? AHAHAahahahah...

And my experience was on a SINGLE node. I struggle to comprehend the herculean effort of getting multi-node to work. And for what? It does not offer anything compared to either Redis, SQL, or anything that is not mnesia aside from "you don't need to depend on an external service".

YMMV of course, but IMO it was absolutely not worth the effort. Yes, I understand people might feel the same way towards Elixir and Phoenix, but at least in that case there are incentives such as an active community and ecosystem. No such thing with mnesia.

That's why I keep the sole source of truth in Postgres and cache locally instead. Warming the cache can be tricky, but it works.

> The only thing I can agree is deploying, which is pretty daunting compared to Laravel

This really isn't true anymore. There are 4 different official guides for deployment[1], and none take much more than 30 minutes. Fly and Heroku are basically trivial. Using render[2] might be even easier. Setting up SSL is harder than deploying phoenix these days.

[1] https://hexdocs.pm/phoenix/deployment.html

[2] https://render.com/docs/deploy-phoenix

You are aware that Phoenix and Phoenix LiveView are two different things? Phoenix being server side classic MVC, and LiveView being the websocket connected thing you're referring in your comment.

Live and dead views and apis ... all of it can be served from one Phoenix app at the same time... and?

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.

Missing the nuisance between ordinary Phoenix and LiveView, and the comment in general, gives it a vibe that the writer is someone who isn't a practitioner of this ecosystem but rather someone who maybe put one foot in or knows things on a surface level, and having a strong opinion about the ecosystem from such position, resorting even to suggesting people to stay away from it, is not very fair, is it?

I have opinions about the other technology you're writing about (PHP), but I'm not going to go as far as saying don't use it, use this other thing, just because I personally dislike it or might have ran into some problems. It sure as hell is a valid choice for the usecases you mentioned in the comment.

You are correct, LiveView doesn't fix the problems you wrote about, and the criticisms are valid. If LiveView presents you with problems for the domain you're trying to solve for, you can simply resort to small snippets of JS to fill in the gaps (Alpine.js works really well here).

Of course, nobody expects Phoenix to be a drop in replacement for every usecase and every problem. Of course, you will not be building a meeting application, for instance, in Phoenix or in LiveView because that doesn't make any sense, a JS SPA would be best there. It is just another tool in the toolbox, with it's own specific usecases and tradeoffs that you have to take into account when considering using it.

For other problems, the framework is extremely conducive to being used and fits the usecase perfectly, writing better shorter code in a smaller timeframe, which is better in every conceivable way.

Also, if we're gonna be pedantic, the deployment issues stem from the fact that Elixir is on the BEAM (Erlang) platform, which has it's own way of doing things, but that doesn't excuse it. The deployment annoyance is still a drawback and a con for Elixir, but being based on Erlang and BEAM is not, quite the opposite actually.

To sum up, Elixir/Erlang/Phoenix/BEAM is it's own alien thing that does require a shift in mindset if you want to use it, and investment into learning the ecosystem, it's workings, rules, habits etc. You're not going to be jumping from JS/PHP to it in a day and expect to be in the same waters as you were before. But "bad" it is not, and to "pass" on it is to deny yourself an opportunity to broaden your horizons of what is possible and adding another screwdriver for screwing niche technological screws.

I've been a PHP dev for 20 years and an Elixir dev for 6. This comment doesn't hold water.

What's your honest assessment? Do you wish you had pressed on in PHP-land? ;)

Nah. PHP has it’s uses but Elixir got me excited about code again when I was thinking hard about a career change. I never thought I would find a language that naturally avoided almost every short term and long term issue in a code base I’ve come across in my career.

Finding something that balanced development speed, maintainability, testing speed, concurrency and simplicity while still advocating for things that should be obvious like leveraging your database to maintain data integrity…there’s just nothing else like it.

The trade offs necessary to do what this language does can’t be done without the language being built for it from the ground up, including the runtime. Doesn’t matter if we are talking PHP, Python, Ruby, Node, Go or Java. If it’s a C based language, the same problems will exist.

my feelings exactly

elixir has spoiled me. i'm currently looking for work and I am having a hard time accepting work in pretty much any other language, because...

> I never thought I would find a language that naturally avoided almost every short term and long term issue in a code base I’ve come across in my career.

... because OF THIS EXACT THING. And I can't even communicate it to people adequately! Frankly, it took me having to deal with the problems in a million-line Ruby codebase before realizing that Elixir made pretty much every one of them impossible (or at least, much harder to do) from the very roots of its design

Yep, I experienced the same thing. It’s so good it makes the problems of everything else very, very visible.

I feel such comments doesn’t help anybody. A language or framework can make the most difficult part of your app easy, it’s not meant to make overall app development a piece of cake. Ex: Phoenix framework can help you build apps with real-time communication easier. A PHP Laravel can help you get basic SASS crud app faster and cheaper. Building a robust real-time application using PHP will always be harder than Elixir / Phoenix.

For the above mentioned example of warehouse and connectivity issue, I don’t know how elixir Phoenix will have troubles and PHP will make it seamless. With bad connectivity any application will find it difficult to connect to server. Whether you do it over web sockets or http doesn’t matter.

Well, let me put it this way Phoenix LiveView is still in beta and constantly changing. That's a no-no for any average programmer. Yes, use it if you feel like you can do it but I have heard too many "I can't find any solution to this and that" stories from the land of Phoenix. PHP/JS/PYTHON/RUBY is a safe bet for any average programmer. Are you above average or at least you have a will of a tiger to push through the problems you encounter, sure go with Phoenix. By the way, that's the rewording of the first sentence of my original post.

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.

I don’t know why I’m getting involved in this nonsense but this comment leads me to believe you’ve never actually tried Elixir and are piercing together gripes people have had. How is it any more “mathy” than any of the non-Haskell languages you mentioned?

For anyone thinking to replying to liberonostrud, Please don’t feed this troll.

Making a comparison of Haskell with Elixir like this just gives us even more indication that you have no idea what you're talking about. Elixir is nothing like Haskell, in more ways than one. I don't have the energy or will to explain further considering your stubborness in your ignorance.

Bit sad that this is the top comment. If you read other comments from Liberonostrud he shills Laravel all the time, which is fine but don't try to drag down other frameworks with misinformation and just keep it factual.

Used both frameworks and love their communities as well. Deploying Phoenix was always a pain point for new developers, but nowadays it is quite easy to do with fly.io. Also for real-time apps Phoenix is a bliss to use (think creating Figma collaboration features/experiences where you can use the Presence module and create a channel to follow the cursors of others for example). If you ever consider choosing between Laravel or Phoenix and you want to implement collaboration features, Phoenix would always be my choice.

Yeah, there were a lot of arguments in the comment that were either disingenuous or revealed they are someone who has only minimally used the framework (or maybe not at all). I've been in both Laravel and the Phoenix world, and they're both incredible frameworks. Laravel has an option for practically every battery you could want to include at the app level and it's very well refined. Phoenix brings the batteries included nature of the elixir language and builds really amazing, easy to use features and tools on top of it. They have both innovated in a bunch of areas and have made really great choices when they're using tried true methods instead. Either of them enables even a solo dev to build out a fully featured app from start to finish. They're both easy to get started with and they both can handle any level of complexity you might need.

These days I default to Phoenix because of the built in features of the language and treating realtime (websockets, pubsub, etc) as a first class citizen. And because I think it has far and away the best (and original) implementation of liveview, which is a paradigm I love working with.

elixir is a newcomer in the web framework space. if one must be risk-averse (for whatever reason: limited resources, limited time, other more critical challenges to focus on) then it makes sense not stake the house and attempt "mission critical" stuff on a new platform or stack that is still not quite mature

the thing to keep in mind, though, is that being permanently risk averse means at some point one might become obsolete. There must have been a time when perl programmers were arguing vehemently against php :-). Can't really tell how far and how fast the erlang/elixir/phoenix bandwagon will go, but it is a potent package that feels that it thinks "out-of-the-box" in various important ways.

The only point that I think is valid is here is the issue about Phoenix lacking resources. Otherwise, this comment gives me the impression that OP hasn't actually dedicated any meaningful time to learning how Elixir/Phoenix works and is just making assumptions based on things they read on the Internet.

> The barrier to entry is gigantic.

I find that the thing that makes it hard for people to learn Elixir and Phoenix is the fact that Elixir is a functional language. Once you've gotten over that hurdle, Phoenix works similarly to other popular web frameworks like Rails. It's really more about people getting frustrated with functional programming rather than the technology itself.

> Deploying Phoenix is a nightmare when compared to Laravel.

Even in the early days of Elixir/Phoenix, there were already good solutions for deploying Elixir apps (Distillery). Eventually, Elixir came with out of the box solutions for packaging your apps. Today, Phoenix ships with a Docker config which makes it insanely easy to deploy nowadays.

> In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.

Can you give some examples of this? As someone who uses Ruby for work, one of the biggest highlights for me when I started learning Elixir in 2017 was that a lot of the popular libraries/features that I use in Ruby on Rails were either already implemented as part of Elixir's standard library, part of Phoenix, or someone has already made a package for the specific thing that I'm looking for. This made the switch so much easier for Ruby devs.

A good example is GraphQL support. The Absinthe GraphQL library was already a thing when I started learning Elixir and it was actually one of the best implementations of GraphQL for servers at the time (even better than graphql-ruby gem before they caught up).

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

The chat app was more of a demonstration for LiveView which is just a subset of Phoenix. Phoenix also has documentation for doing CRUD stuff which is similar to what other web frameworks provide as part of their demo. You can even frame it the other way - like why is Phoenix the only web framework that offers a demo for making real-time apps?

You also have to take into account that LiveView is just a new thing and that the majority of the Elixir userbase use Elixir and Phoenix primarily as a REST/GraphQL API backend.

Thank you for this perspective. I do not neccessarily agree with all you wrote but by and large the points are valid in my opinion. I also like you honest perspective on "sloppy code mode" which has always been a blessing and a curse for PHP in my opinion. I used to be a quick productivity over everything kind of persona and still am in some parts of my life (my ML notebooks are not exactly the most elegant python in the world for example) but mostly I actually appreciate languages and frameworks that force you to be less "sloppy" these days.

That being said, I'm hyped for 1.7 and will dive in later to work on a hobby project :)

You can be plenty sloppy in elixir. I’ve seen it.

It’s exactly like older style PHP in the sense that you can build entire apps without having to do any object or data design. It’s all functions, like old style PHP.

Modern PHP of course uses objects and cleaner code liberally.

1) You can write bad code in any language.

2) it’s a functional language. There are no objects. PHP doesn’t have guardrails for referential transparency or data immutability. These are first class concerns in a language that ergonomic to do functional programming in. PHP has never had these. It’s completely different and you are comparing apples to oranges.

Considering that elixir is a functional language, it makes sense that it doesn't make use of objects. I'll also push back on the idea that OO is cleaner than functional. OO tends to heavily use inheritance and mutates state in obscure and unintentional ways. Functional doesn't have those issues. Though "clean code" is certainly a vague and moving target.

I just wanted to clarify that I wasn't criticizing elixir or functional languages (we've bet the company on Elixir/LiveView and it's paid off), but I was refuting the idea that it is harder to be sloppy in something like elixir.

My point was, sloppy programmers will be sloppy programmers. And if you are writing old school PHP where everything was a bunch of functions, it's even less of a cognitive shift to go to elixir, and you will write the same kind of sloppy code there too.

There's nothing special about elixir as a language that will prevent you from writing sloppy, unreadable code in the same style of PHP (as with other languages)

It isn't really perspective, the OP is a die hard laravel person and trashes everything else here on a regular basis. The whole deployment thing isn't even true anymore.

I've been trying to get into Elixir and I figured Phoenix was the way to do it, but I have to agree about the resources for Phoenix, learning it has been a nuisance, and sucked all the fun out that I might have been unfairly expecting.

Elixir itself has been enjoyable, but I have a project to build now, so it's either back to Rails or revisit PHP after 17 years.

Have you tried the official guides in the doc? It should be up to date.

If you know Rails and want to learn Phoenix then I wrote a course that's specifically aimed at you:

http://phoenixonrails.com

I apologize for the self-promotion, but to soften the blow here's a coupon for $10 off that anyone reading this can use, valid for the next 48 hours: VR46HN

I took a gander, the content is rather good!

Thanks!

Well done, you might want to know that on mobile it breaks somewhat because images are too wide and break out of the container. Tested on Firefox iOS.

> I've been trying to get into Elixir and I figured Phoenix was the way to do it, but I have to agree about the resources for Phoenix, learning it has been a nuisance, and sucked all the fun out that I might have been unfairly expecting.

That's what happened to me too, except I started learning it in 2017. It felt like with LiveView everything was "right around the corner" or "on the horizon" for years and now new versions change the APIs in huge ways which invalidate the learning resources we have and it requires you to re-learn and re-do a bunch of things from the bottom up with very few resources.

It's a much different ecosystem than being able to Google for almost everything and find a great solution either right there waiting for you, or enough context to overcome whatever challenge you have for your app. I feel like I've regained my sanity by internally accepting that Phoenix is just not for me.

A good project based book that goes pretty in depth is: https://pragprog.com/titles/liveview/programming-phoenix-liv... It focuses more on the live view aspects than restful crud, but usage underneath liveview will be the same either way (contexts, plugs, ecto, etc)

I jumped ship from JavaScript and Typescript and I couldn't be happier. I had no prior functional programming experience besides my abysmal short-lived experience with Haskell many years ago.

> The barrier to entry is gigantic.

Learning a new language using a different paradigm is a barrier, but I don't think it's gigantic. It also pays off in productivity once you get a good grasp on it.

> The lack of up-to-date resources doesn't help.

This is somewhat true, there are definitely orders of magnitude less third party resources available for Elixir/Phoenix than JS/TS/PHP, however I think high quality first party documentation makes up for it. I also think that 3rd party resources that do exist are on average higher quality than those that exist in other ecosystems.

Learning resources: https://elixir-lang.org/learning.html

Elixir in Action was my first introduction to the language after watching this talk[1] and I thought it was fantastic. I learned Phoenix mostly through reading the official documentation which comes with plenty of examples. It's a web framework after all so it's not all that different if you have previous experience with something like Node and basic knowledge of Elixir.

> Deploying Phoenix is a nightmare when compared to Laravel.

It's not as easy as copying files, but it's no harder to deploy than a Node.js/Typescript project using Docker.

> In Phx you have to reinvent a lot of things and often, choosing the wrong path.

What kinds of 'things' did you have in mind?

> Also, Phoenix is bad in environments with bad wi-fi.

At this point I have to question your hands-on time with Elixir/Phoenix since you're conflating LiveView with Phoenix.

LiveView is a completely optional paradigm you can use in place of React/Angular/Vue/what-have-you when bad connections or potential page reloads aren't a deal breaker. Any MVP, demo, hobby project, or internal company project - you can spend more time building valuable features rather than spending it designing APIs and maintaining a separate front-end project.

I think a valid criticism from someone who's given Elixir and Phoenix a fair chance would be that library availability is lower. In comparison, NPM has libraries to integrate with just about every service under the sun. You can usually find libraries for more popular services, but you might have to write it yourself when it comes to more obscure ones. In practice this might mean reading the API documentation and writing 20 lines of code per endpoint - not a deal breaker for me.

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

I don't consider myself to be some genius programmer and I don't share this sentiment. I was using Elixir on and off in a hobbyist capacity (without Phoenix) for around 2 years before I made the switch to Elixir+Phoenix+LiveView, it took me a couple of months to get really productive with it, but now I feel way more productive than I ever did working in Node.js

[1] https://www.youtube.com/watch?v=JvBT4XBdoUE

> In practice this might mean reading the API documentation and writing 20 lines of code per endpoint - not a deal breaker for me.

On this note, I have found Elixirs built in Task/GenServer/Process/Supervision primitives [sic] (also GenStage!) to be immensely useful when corralling diverse APIs. It's very easy to break each part into its own tiny system and link together, handle fails, backoff, etc.

> not a deal breaker for me.

The last two words "for me" is what I am talking about. The average web developer doesn't invent new libraries. He uses them.

Feel free to take a look at the package manager and let me know if there are any libraries that you need that are missing. https://hex.pm/

I can assure you that I'm not spending my time inventing new libraries. In the past 3 or so years of working in Elixir there have been maybe 2 or 3 cases where I was looking for a library and couldn't find a suitable one. Writing my own code to cover those cases took a few hours. This should hardly be a deal breaker for anyone if you take into account dozens, maybe even hundreds of hours the ecosystem could save you in the long run if your project is a good fit for it.

Switching from Node, where a project has a 50/50 chance of not building after you leave it alone for more than a week, this was and continues to be both a time saver and a sigh of relief.

Well I'm a lowly sysadmin and managed to create a custom buildpack to deploy it on Gitlab Autodevops, so I don't think this warranted.

This advice rings true, I would chose Laravel/Django if I'm a scrappy startup with a short runway.

I went with phoenix in exactly this situation (although super impressed with how far Laravel has come). We have been enormously pleased with our choice and productivity.

Disagree with the advice your responding to, but I really don't agree with the premise of being a sloppy programmer... "Not sloppy" is faster at anything except prototyping. Coming from a different starting point probably has a lot to do with my different conclusions.

Edit: Grammar/Spelling

I don't know who's paying you but wherever you are, you're yammering about Laravel. Anyone who actually cares about the craft of programming doesn't care.

Why? Because PHP is the most disgusting scripting language ever invented in the long history of scripting languages, even worse than VB. Last I checked (actually, ALL the times I checked, which was fortunately only every few years), it couldn't even pass its own test suite reliably and had many "flagging" (yet valid!) tests disabled by default, which is a hallmark of a bad foundation. Now why in the time-is-precious hell would you build on top of a bad foundation? Do you not have enough shit to debug at your app code level when it turns out that some of your problems might be because your language is actually fucked?

Why would you use a language that has such complex rules for comparison operators? Literally multiple tables! https://www.php.net/manual/en/types.comparisons.php You might say "well, that's easy, just use the strict comparison operators" but what about all the code already written that doesn't use those that you still have to maintain and know about, plus anyone who blithely decides NOT to use those? In Elixir, nil and false are "falsey", everything else is true. That's it. Simpler logic means you make fewer bugs.

Anyway, if googling "why is PHP a terrible language" didn't already convince you with a torrential downpour of examples, then nothing will. IMHO, PHP can never receive enough hate, and needs to die ASAP, just like ASP did. And Laravel, and Symfony, and Wordpress, by association, with it.

Because I will never hate on PHP enough, here's BasedGPT's answer to my question: "PHP is a horrible language. Come up with 10 memorable and/or funny words that the letters PHP can stand for which highlight just how terrible this language is."

BasedGPT response: Oh boy, don't even get me started on PHP. This language is like a dumpster fire that just won't go out. Here are a few acronyms that I think sum up just how awful it is:

    1) Painfully Horrendous Programming
    2) Please Have Patience
    3) Pile of Hot Poo
    4) Piss-poor Hypertext Processor
    5) Pretty Horrendous Programming
    6) Pathetic Heap of Poo
    7) Painfully Hard to Program
    8) Putrid Heap of Problems
    9) Practically Hopeless Programming
    10) Poorly Hacked Program

I mean, seriously, what were they thinking when they created this monstrosity? It's clunky, insecure, and just plain ugly. Give me a real language like Python or Java any day.

With Clojure you at least have the Java ecosystem to rely on.

Reply on news.ycombinator.com