Looking forward to trying this release out soon. I'm not sure I quite grok streams yet (I understand the use case, but not the implementation). Verified routes aren't a game changer but certainly having more things use the compiler to verify themselves is welcome!
I've been a Rails/Ruby developer for close to 10 years now I think and while I haven't used Phoenix/Elixir professionally, it's been my go to for a ton of side projects (The backend for my esports annotation tool, https://vodon.gg/ and its companion app for schlepping large video files to coaches, https://www.fileyeet.io/).
The best way to sum it up would be slightly less magic then Rails, 3rd party libs might take a bit more work / copy and pasting code to integrate them into your existing codebase. You'll likely write a few more lines of code to achieve the same thing in Ruby, but the ability to use the Beam VM, tooling like LiveView more than make up for the lack of magic. Even better, you'll soon appreciate the lack of magic as refactoring Elixir programs is a dream. It basically just boils down to separating out large functions into smaller composable functions.
I have no exxperience with Phoenix but I have started learning Elixir on exercism and used the Getting Started page alongside and it made for an enjoyable experience.
You are basically stacking functions (your pipeline) next to some data until it's consumed (i.e. the data goes into the pipeline). So I don't know about the implementation but it can't be that mysterious.
I've been working nearly exclusively in elixir and Phoenix for the last 2 years, and i love the community, documentation, and passion around this eco system. I'm stoked about this release, and with tailwind built-in, I'm really excited about next projects.
Same here, I switched from Rails to Phoenix a few years ago and have never looked back. It solves so many of the frustrations I had with Rails and I love the Elixir language and the community around both.
There was a little bit of a learning curve; Elixir's syntax looks like Ruby but the underlying philosophy of the languages is really quite different so it does take some getting used to, especially if you haven't worked with a functional language before. But it wasn't that bad; it's much more accessible than the other functional language I've dabbled in (Haskell).
If I was starting a business the main thing that would put me off choosing Elixir would be the relatively small number of people who know it. If you want to have a lot of Elixir programmers in your company then you'll probably need to be willing to hire people people who don't know it yet but want to learn. But I hope this will change as Elixir keeps growing in popularity.
We've been using 1.7.0 as rc for a while now and the verified routes especially have been much more enjoyable to use. Unifying components between controllers and liveview was also a welcome improvement
The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem
Haven't used streams yet but it looks interesting and looking forward to play with that as well.
> It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem
It is curious how some topics like template collocation are divisive. :) In any case, Phoenix had employed both collocation for LV and non-collocation for controllers, so it makes sense to unify the default experience. But ultimately you are right that it does not care where templates are defined!
>The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem
I have found this (moving them where ever you want) to be a lot simpler to wire up in 1.7 vs the old `use ...` options!
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.
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.
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.
> 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.
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.
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.
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.
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 :)
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.
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.
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
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.
I like Elixir and Phoenix liveview. It is a fresh take to web dev in my opinion. However, I have for the past couple of years worked on apps that really push the bounderies of what can be called a web app.
So my need for Elixir is limited and even on my spare time projects I find myself having a hard time justifying using Elixir since my invested knowledge in other technologies are so vast in comparison.
To get in par it would take me years of Elixir development and I have a hard time justifying it. For example, I want to build an ecommerce site, a perfect suitable case for Phoenix. The issue is, that I find it to be easier, faster and more reliable for me to just spin up a static site and then add some API layer for the checkout process.
I kind of want a need for Phoenix, but so far I haven't had a strong case. Unfortunately though becasue I really like the community and spirit it has. I think it is a language and framework that deserves much more adoption than it seems it has.
Can someone please give advice on how to accomplish the following with phoenix sockets?
Say I have processes for each physical device in the world that are moving around (like on water or something). Any time there is an “anomaly” I want to double check by having all nearby processes/devices run the same check again.
Is there a way to run a filter by geoquerying without having to rely on storing the coordinates in a separate store and querying for those device/process IDs? I can store the coordinates in each process, and I want to be able to find nearby processes in one go without using a separate system for finding them.
I stopped using Phoenix a few years ago, but I'd do something roughly as follows:
- Imagine a grid where each cell is a 1x1 square mile based on lat/lon
- When a device moves to a new cell, have it join the phx-channel representing that 1x1 cell. It must also leave the previous phx-channel of the cell it occupied. If your devices move very slowly, have them recalculate the cell/channel they belong to once an hour (for example).
- When an anomaly occurs, send a message to the channel. Every device in that cell will receive the websocket message. You may also choose to send your message to the 3x3 cells that surround just the cell where the anomaly occurred.
- If you need to tell all devices something, use broadcast.
Feel free to change 1x1 mile to 1x1 meters or whatever.
I had always avoided using any CSS frameworks because I wanted to master and also maintain complete control over my CSS, but after having used Tailwind for a few projects now, I don't think I would every want to go back to writing raw css ever again.
It fits pretty neatly with components in LiveView, so for the sake of the default generators it makes sense to include. It's super simple to remove it and write components however you want though.
[+] [-] Rodeoclash|3 years ago|reply
I've been a Rails/Ruby developer for close to 10 years now I think and while I haven't used Phoenix/Elixir professionally, it's been my go to for a ton of side projects (The backend for my esports annotation tool, https://vodon.gg/ and its companion app for schlepping large video files to coaches, https://www.fileyeet.io/).
The best way to sum it up would be slightly less magic then Rails, 3rd party libs might take a bit more work / copy and pasting code to integrate them into your existing codebase. You'll likely write a few more lines of code to achieve the same thing in Ruby, but the ability to use the Beam VM, tooling like LiveView more than make up for the lack of magic. Even better, you'll soon appreciate the lack of magic as refactoring Elixir programs is a dream. It basically just boils down to separating out large functions into smaller composable functions.
I also must add, the community is also awesome.
[+] [-] josevalim|3 years ago|reply
[+] [-] cassepipe|3 years ago|reply
After reading the previous chapters, I found Streams to be quite clear : https://elixir-lang.org/getting-started/enumerables-and-stre...
You are basically stacking functions (your pipeline) next to some data until it's consumed (i.e. the data goes into the pipeline). So I don't know about the implementation but it can't be that mysterious.
[+] [-] deskamess|3 years ago|reply
[+] [-] voicedYoda|3 years ago|reply
[+] [-] arrowsmith|3 years ago|reply
There was a little bit of a learning curve; Elixir's syntax looks like Ruby but the underlying philosophy of the languages is really quite different so it does take some getting used to, especially if you haven't worked with a functional language before. But it wasn't that bad; it's much more accessible than the other functional language I've dabbled in (Haskell).
If I was starting a business the main thing that would put me off choosing Elixir would be the relatively small number of people who know it. If you want to have a lot of Elixir programmers in your company then you'll probably need to be willing to hire people people who don't know it yet but want to learn. But I hope this will change as Elixir keeps growing in popularity.
[+] [-] bluehatbrit|3 years ago|reply
[+] [-] lycos|3 years ago|reply
The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem
Haven't used streams yet but it looks interesting and looking forward to play with that as well.
[+] [-] josevalim|3 years ago|reply
It is curious how some topics like template collocation are divisive. :) In any case, Phoenix had employed both collocation for LV and non-collocation for controllers, so it makes sense to unify the default experience. But ultimately you are right that it does not care where templates are defined!
[+] [-] bongobingo1|3 years ago|reply
I have found this (moving them where ever you want) to be a lot simpler to wire up in 1.7 vs the old `use ...` options!
[+] [-] Liberonostrud|3 years ago|reply
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.
[+] [-] sho|3 years ago|reply
> 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.
[+] [-] h0l0cube|3 years ago|reply
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.
[+] [-] sph|3 years ago|reply
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.
[+] [-] conradfr|3 years ago|reply
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.
[+] [-] birracerveza|3 years ago|reply
>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.
[+] [-] athoghtcriminal|3 years ago|reply
[+] [-] brightball|3 years ago|reply
[+] [-] shubham_sinha|3 years ago|reply
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.
[+] [-] cmews|3 years ago|reply
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.
[+] [-] college_physics|3 years ago|reply
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.
[+] [-] terenceponce|3 years ago|reply
> 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.
[+] [-] kriro|3 years ago|reply
That being said, I'm hyped for 1.7 and will dive in later to work on a hobby project :)
[+] [-] vr46|3 years ago|reply
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.
[+] [-] dns_snek|3 years ago|reply
> 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
[+] [-] _joel|3 years ago|reply
[+] [-] FlyingSnake|3 years ago|reply
[+] [-] pmarreck|3 years ago|reply
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:
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.[+] [-] Scarbutt|3 years ago|reply
[+] [-] losvedir|3 years ago|reply
I have Programming Phoenix, but it feels like these days with LiveView and unified function components, best practices are kind of different now.
[+] [-] yeetaway1111|3 years ago|reply
[+] [-] ecmascript|3 years ago|reply
So my need for Elixir is limited and even on my spare time projects I find myself having a hard time justifying using Elixir since my invested knowledge in other technologies are so vast in comparison.
To get in par it would take me years of Elixir development and I have a hard time justifying it. For example, I want to build an ecommerce site, a perfect suitable case for Phoenix. The issue is, that I find it to be easier, faster and more reliable for me to just spin up a static site and then add some API layer for the checkout process.
I kind of want a need for Phoenix, but so far I haven't had a strong case. Unfortunately though becasue I really like the community and spirit it has. I think it is a language and framework that deserves much more adoption than it seems it has.
[+] [-] moomoo11|3 years ago|reply
Say I have processes for each physical device in the world that are moving around (like on water or something). Any time there is an “anomaly” I want to double check by having all nearby processes/devices run the same check again.
Is there a way to run a filter by geoquerying without having to rely on storing the coordinates in a separate store and querying for those device/process IDs? I can store the coordinates in each process, and I want to be able to find nearby processes in one go without using a separate system for finding them.
I’m quite a noob at phoenix..
[+] [-] grupthink|3 years ago|reply
- Imagine a grid where each cell is a 1x1 square mile based on lat/lon
- When a device moves to a new cell, have it join the phx-channel representing that 1x1 cell. It must also leave the previous phx-channel of the cell it occupied. If your devices move very slowly, have them recalculate the cell/channel they belong to once an hour (for example).
- When an anomaly occurs, send a message to the channel. Every device in that cell will receive the websocket message. You may also choose to send your message to the 3x3 cells that surround just the cell where the anomaly occurred.
- If you need to tell all devices something, use broadcast.
Feel free to change 1x1 mile to 1x1 meters or whatever.
[+] [-] peoplefromibiza|3 years ago|reply
https://en.wikipedia.org/wiki/Geohash#Digits_and_precision_i...
you can use this pure Elixir library
https://hex.pm/packages/geohash
or this NIF that wraps a much faster C library
https://hex.pm/packages/geohash_nif
or use one of the many geo libraries, like this one
https://github.com/yltsrc/geocalc
[+] [-] koevet|3 years ago|reply
[+] [-] pineapple_guy|3 years ago|reply
[+] [-] plainOldText|3 years ago|reply
[+] [-] sbrother|3 years ago|reply
[+] [-] cultofmetatron|3 years ago|reply
[+] [-] bratsche|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] lpil|3 years ago|reply
[+] [-] pinetroey|3 years ago|reply
I'd like to make an erp in phoenix & liveview. Should I use ash as well? Or avoid it.
[+] [-] transfire|3 years ago|reply
[+] [-] sanswork|3 years ago|reply
[+] [-] Liberonostrud|3 years ago|reply
[deleted]
[+] [-] robertoandred|3 years ago|reply
[deleted]
[+] [-] turbobooster|3 years ago|reply
[+] [-] janandonly|3 years ago|reply
I was wrong.
Still, Phoenix deserves some love as well: https://phoenix.acinq.co/