Ask HN: So, what's up with Phoenix (web framework)?
While I have noticed that Phoenix is a thing people are generally happy about, I was surprised to see, that it beats the Loved/Dreaded section of the current stackoverflow survey by a staggering 20% over Express and RoR.
I suspect this is due to some rather fanatical following and coordinated effort to skew the outcome. Still, I am curious, specially since the latest blog update is nearly from one year ago, which gets me at least a little suspicious in web world.
Any takers? What's the current feeling around Phoenix? Is is the end all superior fullstack framework (at least form the devs side) this survey makes it out to be?
142 comments
[ 2.2 ms ] story [ 184 ms ] threadIn general Elixir is a bit more quiet that way, but that doesn't go to say its not nice to use.
(Apparent) activity of a project relative to how active the overall space is seems like a decent metric to look at.
https://trends.google.com/trends/explore?date=today%205-y&ge...
Phoenix is really lovely, I’ve been using Absinthe the GraphQL add on and it’s been awesome and for the first time I’m starting to play with channels and web sockets which are really so well done and so scalable. The only thing I’d really like is types and better introspection support in my editor but pattern matching often can be used to simulate runtime duck typing to a certain extent protecting you even if your program will still compile.
Maybe worth trying it out as Elixir and Phoenix are quite simple compared to a lot of magic you’ll see in OOP programming languages.
We should never underestimate the value of building on solid foundations. This may not be as intuitive with software as with, say, buildings. But it's just as true. Start with a language slapped together quickly and you end up with tonnes of unnecessary headaches down the line. Start with one built around the main problem it's trying to solve, with a lot of foresight and early improvements built in, and you eliminate whole classes of problems.
> I keep reading the false dichotomy that languages/frameworks either evolve (and therefore break code) or stagnate (and are stable) while there is plenty of evidence in both old (C#, Erlang, etc) and new (Rust, Go, Elixir, etc) that you can evolve without breaking code. [1/4]
https://twitter.com/josevalim/status/1560552538004389890
It’s hard work, but breaking changes should be rare. As a happy C# dev, very rarely is anything broken over here. Some obscure changes were made for the upgrade to 4.8 and .NET 5.0 but there are significant benefits.
For 95% of web apps, I'd say Phoenix is the best option these days. It just solves a whole class of problems that send users of RoR and JS frameworks reaching for Redis, Sidekiq, etc. It's also great in terms of debuggability, which I'm now seeing in a project I've taken over that has immense technical debt.
As far as community buzz, I'd say it's been a slow, gradual growth. There have been more books, conferences and podcasts than I'd have expected for the size of the community, but it's still a fairly young and niche language.
The biggest weakness is lack of 3rd-party support. E.g., Stripe documentation will leave you hanging if you don't use a language they've written a client for: https://stripe.com/docs/payments/checkout/fulfill-orders
As for Stripe, some client developers have been code-generating their client with mixed success. ExAws, however, is essential.
Obviously running mnesia on an auto-scaling group makes about as much sense as running postgres on one.
So the missing context is ERTS, I suppose.
In my experience, Mnesia works best if you can ensure an orderly sequence of online nodes, but unless you use ram_copies tables, the data is persisted to disc, with journaling, so it's recoverable as long as you have an orderly sequence of nodes in general.
By orderly sequence, I mean that you don't lose access to a node thatis the sole holder of data. On hard provisioned systems, two geoseparated pairs of two nodes should be more than sufficient, but don't get them all storage from the same batch and turn on everything at once. You might want to add a fifth node somewhere if you want to pursue a majority transaction setup. If your nodes are more ephemeral, you probably want three (or more?) per location so you have a better chance of data migration within the location. If you can provision network storage with good persistance forecasts, you could look into storing snapshots (and maybe journals) there, but that's not an out of the box experience.
As much as possible, you want to put nodes that store redundant data in different failure domains; not in the same rack attached to the same switch and the same PDU. Of course, there's connectivity benefits of being close too, so you have to weigh the risks with the benefits.
https://elixirforum.com/c/phoenix-forum/20
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
- https://www.fastify.io/
- https://github.com/uNetworking/uWebSockets.js
- https://github.com/kartikk221/hyper-express
uWebSockets.js beats both on performance benchmarks. In fact it beats everything based on Node's built-in http module, such as fastify, hapi, koa.
https://github.com/uNetworking/uWebSockets.js
I’ve been consulting with a few startups and it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary.
ATM I’m working on a few side projects and I’m enjoying being able to build all of the functionality necessary alone without reaching for anything outside elixir+postgres.
The biggest issue is a pretty steep learning curve and lack of beginner friendly documentation, lots of tinkering and code reading is necessary when starting.
I've also really enjoyed Pragmatic Studio's course on OTP where they build a genserver from scratch, thay was eye opening, a few more in-depth courses would definitely be welcome.
Agreed on Pragmatic Studio's course. It's probably my favorite video resource for OTP, my favorite overall resource being Saša Juric's book, Elixir in Action.
What is meant by sagas in this context?
Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.
Is there any reasons why that should be avoided or why you don't want to expose a proper API for that?
Welcome to the world of distributed systems. Who owns what piece of state is the perennial difficulty that has plagued developers forever.
You are right though, responsive testability suck with liveview (and honestly just about any be+fe system). I don't see why in the long run it shouldn't be possible to shove a JavaScript engine into the VM (I played around with doing this with mozjs for a bit -- may come back to it) and use it to store a dom for testing.
Probably because they decided to use microservices (read: distributed systems) for no God-loving reason.
Acknowledging that opens up a whole world of already thought through solutions to problems in distributed systems.
Although to be honest it boggles my that it's possible to accomplish this on iOS.
Phoenix gives me a network synced crdta backed data structures, multicluster websocket support with long polling fallback, supervision trees with long lived processes and a descent pubsub system out of the box. we've gone 2 years in production and haven't needed redis or rabbitmq yet. its allowed us to focus on delivering features without drowning in infrastructure.
I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. Phoenix very much doesn’t suck. But it simply got all the basic right and then the true benefits come from it running in elixir/beam, which means you can skip all the job runners, redises, microservices etc.
I don’t know where you got the idea from that something is up with it. It’s chugging along great.
I think you captured something I've been mulling about recently. The perception of software quality should be on an inverted scale, like incident severity where zero is the worst possible outcome. Software can't be better then "works well, has little accidental complexity". But it can be much worse than that. People rave about pieces of software that do their job and get out of the way because they're so rare, and not because they are magical unicorns that cook you breakfast and give you massages. But because they fulfill expectations at a reasonable cost.
Also in Django you can easily follow the code to understand what's going on under the hood. This is not very easy in phoenix since macros are involved.
Don't get me wrong I understand that macros are used to make the code more ergonomic and avoid repeating stuff. However macros are so complicated and out of my league that I don't even try understanding them.
You should not need an IQ of 150 to understand a web framework. That's the reason phoenix w could never be widely adopted. People need a tool not a way to show off their intelligence.
Macros are a pretty important feature of Elixir that helped get it wider adoption. Without them, things become incredibly verbose. While I totally agree they can be hard to grok, there is absolutely nothing magical about them as they are expanded at compile-time. You can call `Macro.expand` on any AST and see the static code it generates.
Otherwise, with a good, well-documented framework like Phoenix, the majority of users should be able to just use it as-is without needing to show off their intelligence by diving into the underlying implementation ;) <3
PS, I've never had a problem when there's an error in a macro. The line in my app that failed is always in the stack-trace which is all I ever need to debug (though I do wish is drew my eye to it somehow).
Unfortunately for phoenix, when I started learning it I needed to rely on source code to understand some stuff. Trying to walk around the macro stuff was not a cool experience.
Also I did have some macro related errors most related to ecto and its syntax. See this article to understand the problem
https://www.spapas.net/2019/07/25/declarative-ecto-query-fil...
Ecto has its own, undocumented syntax. If people from the elixir irc (including the always helpful Jose Valim) wouldn't help me I'd be never be able to guess that thingie...
1. The blog post is great and it shows there is indeed complexity around dynamic filters. I would love to see a solution that tackles it all the way down to form rendering :)
2. All of the Ecto API/syntax used in the blog post is documented, afaik.
3. You mentioned in another comment that Ecto does not support associations in queries, but it does: `join: c in assoc(p, :comments)` and that takes care of the ON condition and anything else you configure.
Was that syntax documented 3 years ago? I don't really remember but definitely even if it was I couldn't find it. Also you should agree that it's non intuitive.
Finally, you are right about assoc, I don't use it because I prefer the left_join/on syntax but that's not a correct argument .
Perhaps there are other factors that make Phoenix harder to grasp in your experience but I hope pointing out that it may not be macros help peel some of the complexity away.
Furthermore, if you get a bad stacktrace in either Phoenix or Ecto, please open up a bug report. Macros should not and do not imply bad stacktraces. In a very simplistic way, you can think of the Elixir compiler as a huge macro, and it still strives for great error messages and stacktraces. Many Elixir building blocks are implemented with macros too, and we have great error messages and traces there, and we aim for the same in Ecto and Phoenix.
Router helpers are also kind of a truck. It took me years to understand why you would want them and I still often just hardcode routes in the templates.
Some things in Phoenix are relatively hard if you want to have multiple endpoints in the same app without doing an umbrella.
On the other hand they say consistency is the hobgoblin of the small mind, so I might be guilty as charged in my quest for consistency
The only reason it isn't dethroning RoR is because it will take some time before the ecosystem of plugs can catch up to the amazing ecosystem of gems
Twitter wont let me view more than 3 tweets without making an account so I can't find it...
I actually did pursue static typing (w/ type annotations and Dialyzer) at one point, but quickly lost interest, since it didn't really seem to add much. Having comprehensive tests, on the other hand, was crucial - especially since I could use pattern matching within those tests to make assertions about expected inputs and outputs.
I will say that there were bugs that compile-time type checking probably would've caught, but tests also readily caught them. The same can likely be said for current bugs. It's ultimately the same idea: validate that your code adheres to the expected API and behavior; only difference is that the validation happens in different places.
[1] https://gleam.run/
There was a company hiring lots of Elixir devs that actually hired straight from bootcamps - I forgot the name unfortunately, they had an interview on the Elixir blog or Adopting Elixir book or somewhere like that...
I did find the documentation a little sparse at times, especially when dealing with heavily nested tables (or even just many_to_many relationships were cumbersome to work with).
Things like Plug, hex, pattern matching and so much more have stuck with me and I still miss them almost daily in my current stack.
For everything else I still feel it's inferior to my other framework of choice Symfony (well ok ... maybe not regarding Ecto vs Doctrine, but "transparent" caching would have been nice).
A while back I wrote a small guide on how to design your contexts and its queries for flexibility. Not sure if this will actually answer some on your issues with them.
https://elixirforum.com/t/a-design-pattern-for-more-flexible...
I guess I dislike the code that the context generator produces. A bit like the auth generator that forces you to commit code you didn't write and that is basically a mess to upgrade, and frankly not that great to modify to suit your needs.
I had a crappy auth system I wanted to migrate to it, I had to run the generator and try to update my code with the generated logic. Ugh, not fun.
But regarding contexts, they're just modules. Nothing mandates them, it's just a best practice to collect database functions in their own module, whatever the language. I've never used the context generator.
Phoenix revitalized my interest in programming at a time when I was so frustrated by the state of things that I was ready to change careers.
Some people say ecto is limited. I love that it lets sql be sql. It lets me think of the solution in sql and write that sql almost directly in elixir with better ergonomics (being able to make a subquery a separate variable that I join into is a HUGE improvement over raw sql). Those uses of fragment can easily just be turned into macros that integrate cleanly into ecto when I use them enough.
Thanks for one of the best developer experiences I ever worked with. when I have a side project, I'll be trying fly.io and I've already recommended it to other founders. We be using it if it was at its current state in 2020.
Phoenix ain't quite my cup of tea for the same reason Rails ain't my cup of tea: it's big, and it does little to hide that bigness. It's why, when I was doing web development on Elixir, I ended up gravitating to alternative frameworks (like Sugar - which, as a disclaimer, I'm a very inactive maintainer of), for the same reasons I tended to prefer Sinatra or Padrino over Rails. For most people, though, "bigness" ain't really a problem - and Phoenix does a really good job of being "Rails but actually good". At the end of the day, it's a solid choice that probably won't bite you in the ass, and that's what matters.
Rails significantly slows down Ruby, while adding a lot of value.
Phoenix has a negligible effect on Elixir performance, while adding a lot of value.
I don't super love Phoenix, because a lot of it's metaprogramming stuff "breaks" elixir conventions, but I have to admit, I've done some really strange things with it and never worried about sleeping at night.
I guess that’s part of the reason why the Phoenix blog is less active?
I just wish I could get a job in it.
In any case, Phoenix is a fine (niche) framework but can't really be compared to a masterpiece like Django:
* Phoenix, probably because of its influences from the ruby world is using some concept called "generators". Using the generator it will generate (sometimes a lot) source code files that will implement some functionality. For example, let's suppose you create a new schema (similar to the django model concept). You can use the generator so it will automagically create code for the schema file, its migratinons, some crud forms and even tests. This works fine until you need add another field to your schema, or you need to rename a field or just do a small mistake! Then you'll need to do some very error-prone and boring work. Compare this to the way that Django uses the Model to generate everything from that using class inheritance and composition, without the need to write any code. Also notice that the phoenix generators can't understand relations and you need to edit the schema and migration files by hand to properly add references.
* No auto-migraton support. That's that. If you add a field to a schema you need to edit the migrtion file yourself. Django automagically understands the changes and will generate the migration file.
* This generator thing unfortunately has influenced various other stuff from phoenix, like authentication (you use generators to create some kind of authentication code which then you need to edit). Again, compare this to the elegance of Django using the authentication backends. Also you use generators for presence, channels, whatever...
* The "ORM" (which is not really an ORM it's more or less a way to talk to the DB called ecto) is miles behind the Django ORM. It doesn't support any andvanced stuff, you need to do the joins yourself (i.e from(u in User), left_join: (a in Authority), on: a.id = u.authority_id, where: u.is_active == true. Compare that to User.objects.filter(is_active=True).select_related('authority').
* Also the ORM doesn't support most of the advanced stuff and you need to use an escape hatch called "fragment" that allows you to write raw SQL.
* Phoenix has no django admin. nuff said.
* The phoenix has some funny controller/view/template architecture (which I also think that was influenced from rails) that isn't very intuitive. The views are more or less useless and everything is like router -> controller -> template. Similar to urls -> views -> template in Django. But having the unnecessary views there adds another level of abstraction making everything more complexfor no reason.
* Things like template inheritance are not really possible in phoenix. You use a thing called layouts to re-use stuff. The Django template inheritance is much, much more powerful and simple to understand.
* Django is much more batteries included: Phoenix has more or less no authentication (beyond the generator generated one I mentioned before), no caching framework (you need to use some kind of extension), no pagination support (!), no permissions and various other things that you'll need to implement yourself or find some obscure library that has 3 years to be updated and doesn't suport the latest phoenix, which gets me to the next point:
* Phoenix needs a JS bundler for its javascript code. It used to use webpack and now uses esbuild. Still, they could just provide the proper compiled JS files and let us decide if we wanted to use any node-js stuff (which I avoid like hell).
* Re-using code among controllers is possible using plugs but definitely not as straightforward as extending class based views with mixins.
* The ecosystem is very very small. Most libraries/extensions are 1 person projects and most of these are from persons that tri...
Only thing I don't agree with is Ecto. I have found it more straightforward to work it and reason about, much because of the functional syntax of Elixir.
But yes, I do hate generators. Adding auth to an existing project was a bad experience, since you need to do a diff to understand changes being added. Not only that, wanting to keep the code clean, removing redundant or completely unnecessary features requires you to understand how the whole thing works. On one hand, great, it's never a bad thing to know every single detail about your authentication. On the other, it's time-consuming, and maybe I would prefer the separate "blackbox" that I can opt-into with clear API which I can always dive into that doesn't mess directly with dev-written code.
Just curious, did you try Torch or Kaffy?
https://github.com/mojotech/torch https://github.com/aesmail/kaffy
For the ORM and auto-generated DB migrations, I actually prefer the Phoenix way. Ecto makes it much harder to trigger N+1 queries than the Django ORM, and in practice I find the explicit migrations make people actually think about what they're doing and what to index, so the schema is cleaner. But I could see why someone would prefer the Django way, and I'd be curious to see the same kind of system in Elixir.
I agree about the n+1. Its a long debate about how useful it is. I understand it is problematic some times but I'd prefer it any time compared to having to declare all joins on my query. Yes, it had bitten me a couple of times when I was new to Django but nowadays select_related and prefetch_related are like a second nature...
I disagree with one point you mentioned regarding configuration. Kaffy requires less configuration to work out of the box with all your schemas. In django, you do need to to write admin.site.register(Foo) for all your models to be included in the admin interface, where in Kaffy all your schemas/models are included by default. Kaffy also offers things that django admin doesn't like a dashboard, static pages, and scheduled tasks.
I suggest you give Kaffy a try and, with your django/phoenix expertise, I'd love to know your feedback.
- I see you dislike generators as much as me ;)
- Template inheritance, it's maddening isn't it? Sadly it does not resonate with the RoR crowd and by extension the Phoenix one. I've been told to use "heex function components" instead but I'm still a bit lost as how this is an appropriate substitute.
- I disagree with your take on "fragment", it's almost my favourite feature of Ecto, as it means you can use almost any functionality of your database/version of choice without specific support from the (not-)ORM.
About the fragment. I agree it is useful but it's usefulness relies on the fact that most non basic sql is not implemented in ecto so you need to be able to use it somehow... Consider that the Django ORM implements almost anything that your gonna need (thing like Case, SQL functions, subqueries, whatever) so you only write ORM code!
I used Django in the past and the "auto-migraton support" feature you are talking about is great but not perfect. It is even mentioned in the official documentation. I have been myself in situations where it created unwanted behavior. So I can understand the Elixir core team not wanting to bet on a feature that is neither perfect nor essential.
> But having the unnecessary views there adds another level of abstraction making everything more complex for no reason.
Hell no! Imagine how much more succinct and clear templates can be just because you moved some verbose logic into helpers defined in your views? I find that Phoenix encourages people, especially beginners, to adopt nice ways to organize their code.
The generators you like them or not but you are not forced to use them. Personally I find that they boost productivity and are a very good learning tool.
Finally I would say that Django did not become what it is in a day. Elixir/Phoenix is perhaps slowly but surely moving towards a future that I am impatiently awaiting.
About the migrations; creating automigrations like django is a ton of work. It handles all trivial and most non-trivial cases perfectly. If you have some really complex stuff you can edit the migration file (it.s normal python).
I don't like organiziging stuff into per-controller views, I usually need to re-use things and create helper views, or other modules having that functionality etc. So their usefulness is diminishing.
About generators, I agree about the learning stuff (I actually mentioned that in my comment). About productivity... hm it depends on how useful they would be.
As for your final comment? I definitely agree; Django is a behemoth framework with more than 15 years of development time and a really huge community of contributors. Phoenix is much smaller both in age and in community so it will definitely be less mature. But I agree that it moves towards the correct goal, especially if you focus on its excellent real-time features where it really shines!
I’ve seen it happen in various degrees to React, Docker, Microservices, Kubernetes, Rust and I’m sure I’m forgetting others.
Certain problems in software are so complex, that there’s no one size fits all solution. The problem with the early fanbase is that it tends to be a self-selecting group in one way or another. When you read someone’s anecdote that library/framework X “was a delight” you don’t always know for example that it was maybe used by a group of 3 devs for a startup pulling $50k in MRR. Will the same apply for you team that is 10x bigger? Maybe. The opposite can be true where you have some project get open sourced by a tech giant which gets adopted by smaller teams with very different needs or resources.
My point is, if you hear outsized praise for something it’s likely because it’s early in the hype cycle or it hasn’t seen enough wide adoption. No solution is perfect.
It’s better to take a look yourself since no one else will know your or your teams needs and preferences. This is where the buzz can come in handy. It can highlight new technologies worth trying out. You’ll usually learn something new in the process.
MFC, vb3,4,5,6, entity framework (every version), OLE, COM, DCOM, ActiveX (all of which were basically the same thing), as2, as3, PureMVC, Cairngorm, Flex, asp, asp server controls, DAO, asp.net, php (and every php framework), Cold Fusion, CFCs, JSP, servelets, beans, spring, dojo, jQuery, ext, Google's JWC, backbone, moo tools, knockout, meteor, angular, angular (x), react
Just off the top of my head of hype trains I've ridden.
Now I'm all about simple.
Express + web components + postgres is the magic combination of simplicity, time to market, performance and community for me these days.
LiveView itself is an interesting concept and while we do use it in production daily for almost 2 years, I'm not yet convinced it's really better than having the frontend be React (or whichever you prefer). It has grown quickly and become much more useful than it started out as.
Ecto in my opinion is the thing I would miss most were I to switch to something else.
First off, Phoenix fixes pretty much everything I didn't like about Ruby on Rails and when I need to write an API for a weekend side project that I need to turn out quickly, I'll choose it without question. If you want to use a convention-based framework that includes support for migrations and instant DB mapping, it works well. The documentation is excellent.
I personally would not choose it for a large enterprise codebase, or for something with a rich Ux that you can't control the designs for (ie. you have a Ux team that calls all the shots).
LiveView is interesting. I have found certain things overly difficult to do that are easy in the js-based frameworks. For instance, a UI that has a list of children that you want to add and remove in memory and then save at the end. Obviously you can do this, and I've done it a lot, but there are quirks with the interaction of changesets, ecto, and your form that make it tricky for newcomers. I think the tight coupling between changesets and the form gets strange as soon as the page gets complicated. Schemaless changesets work well for this, but this is more to add to the learning curve.
Understanding the interaction between LiveComponents and function components will be tricky for newcomers as soon as you are past trivial implementations. Knowing where the memory is stored and what a genserver is is super important, but not intuitive. Targeting a specific LiveComponent to receive events if you have one that has another as a child isn't intuitive. Unit testing a LiveComponent and a function component is pretty sweet, but there's a learning curve there and I ran into a few frustrating bugs that didn't help (they were fixed after a few weeks).
There's a lot of these examples. The interaction with client-side js has evolved a lot this year, but it's tricky in my opinion.
I have personally witnessed experienced, talented and smart Elixir developers struggle with LiveView. The learning curve is real.
I know Elixir people love this stuff deeply, but I don't think LiveView will win in the marketplace of ideas, even if Elixir and Phoenix gain traction. People who aren't already bought in to this stack won't be willing to build complex websites this way. I know Chris and Jose are reading this thread, and I have deep respect for their accomplishment and talent, but LiveView isn't going to be for me.
For example, the new function components are meant to reduce the reliance on LiveComponent and ease the learning curve. We don’t have an answer for complex forms yet.
I truly think the programming model is solid and is the next step in building server driven interactive and real time applications. But we will definitely stumble here and there as we iron out the finer details. :) thanks for the feedback!
I don't think it's any fanatical following, it looks like a lot of other people are in the same boat as me with it. It's just good and effective.
I'm not a big fan of surveys and I'm not sure I've responded to this one actually, but: my current feeling around Phoenix is that it will be my go-to framework for anything web related for the years to come, but also Elixir will be, for larger topics (ML, embedded, data-viz, scripting, etc).
There are a number of important points (to my taste) that comes out of my use of Elixir & Phoenix :
- the maintenance story has been quite good (maintenance work is one of my main line of work since year 2k, I have used many stacks, including Java, .Net, RubyOnRails etc). Upgrades and refactoring & moving code around has been quite easy overall, once you get the stuff right (using Mox etc).
- Phoenix, Ecto & Elixir are a good "generalist web framework" for a lot of use
- Compared to some stacks (non-evented Ruby & Python, for instance), having a part of your app work as a proxy for domain-specific uses, is not a problem, and does not even require you to split that part from the main app (example at https://github.com/etalab/transport-site/tree/master/apps/un..., where we proxy/cache GTFS-RT protobuf & SIRI XML feeds behind rules, adding rate-limiting & hiding target server authentication schemes)
- Similarly, anything real-time is at least initially trivial. For instance, creating this real-time view of moving vehicles (https://transport.data.gouv.fr/explore) with 70+ GTFS-RT feeds has been quite easy (PR at https://github.com/etalab/transport-site/pull/2224). The server side is like "EventMachine done right", and the live updates are broadcasted to each client via web socket. No extra server (e.g. AnyCable) or anything is needed.
From a perf/ops POV, the amount of topics you do not even have to think about is quite important, which is very nice.
Overall I can see myself sticking to this stack for the next 15 years or so, without much worries (I've been coding since 1984 as a kid, so I have a good idea to know when to keep a framework around or not :P)
I am mostly curious if i should try Livewire for next smaller project.
When I wrote apps in other languages in the past, I felt like I was building a big skyscraper. Everything was sorta connected and it was difficult to add new doors into the project. I was sometimes limited to building something I wanted because the runtime just wouldn't allow it.
When I'm writing Elixir, it's like I'm building a city. Everything works in concert, but I could build a small building next to a skyscraper next to another building.
This is because of the runtime, not the language. It's easy to build self contained "apps" that are deployed with everything else but isolated. It let's me build the app I want rather than forcing me into a very specific way of building.
And just to be clear I'm not talking microservice, that would be like building multiple cities connected only by little roads.
I'm work shopping this analogy since it's not as clear and concise as I'd like :)
PS. I'm pretty active in the community and other private communities and didn't know about the survey. I would have a hard time imagining large scale survey orchestration given that.
I’ve never used the language, so no feedback to the value of the claim, but that metaphor does resonate.
I am curious about if redundant state and state synchronization tends to be an issue in medium-to-large Elixir apps? If not, how does one design the component/actor hierarchy to avoid such issues?
This could be an artifact of how I build systems. I have heard of some people that build really small actors and do a lot of data exchange. Without knowing details, I'd lean towards that being an anti-pattern.
If the state is in ETS than (optionally) any process on the node can read the state. Often this is paired with a single process that is allowed to update the state so that the state is always updated atomically. Often this pattern means that you don't need to distribute the same state to multiple processes, because instead they can just read the state they need from ETS (which is pretty fast/cheap).
Sometimes you have requirements where it's hard to assign any given piece of state to a single actor though, that's going to be challenging in any language.
An ETS table (the OTP in-memory key/value database, more or less) is isomorphic with a Process that holds the data, although the reality is different. Mnesia if everything is done with transactions might be as well, although where I used mnesia, we did not use transactions and it was helpful to understand how the data flows between mnesia nodes, and when you might read outdated data.
The fanaticism around them partly comes from disillusionment from frontend development. The pendulum has swung to "server-side was right the whole time!" Disillusionment with Ruby may also be a factor as well. Elixir also makes way more promises around scalability and fault tolerance than any language I'm aware of (yes I know it's using the Erlang VM but no one wants to write Erlang).