Should we adopt Dave's way of building applications as a series of components? (Dave's talk has now been added!)

You’re probably right. Although I find that distinction less important than how wrong the name “application” is :wink:

Phoenix is Rails without a lot of the bad stuff. I get that. We started out just using Cowboy and Plug, but somehow every little service ended up being slightly different, because there is no style to follow. Which is why I recommended we do it “the phoenix way”, but then with the minimum amount of fluff which means taking a chisel and chipping away things until just the core is left.

In terms of problems, spending 15 minutes after mix to clean up is probably not even going to make it in my top-50. I do wonder though about the sort of patterns that we as a community propagate. GenServers mixing API, OTP and Implementation; Phoenix apps mixing two or three entirely orthogonal web-y things (templates, SPAs with JSON APIs, websockets) together with business logic and persistence; etcetera. I think we should have louder warning signs over quick examples “this is not how you are supposed to do it” :wink:


Why not just make up a new name, like the gem for ruby or jar for java? I know a gem or a jar is just a package and that’s not what an OTP application is, but my point is that we do not need to stick to a name that means something. When you first heard gem (or whatever you call it on your previous language) you did not associate everything that was inside there, someone had to explain you.

I’m not suggesting this name for erlang applications, that would be hard to convince them, but we could call it something like flask and say it is totally equivalent to an OTP application. :slightly_smiling_face:

Anyways, my hopes on this kind of change are very small, since a change like that can have its problems. I really am not bothered that much by the name application. :man_shrugging:


We just have to decide:

  • do we want a descriptive name (which is good because it helps to organize stuff defining what should be inside it)
  • or we want to not care about these naming stuff and allow people to do whatever they want inside their flask/howeverwenameit (which is good because MAYBE we would not have these discussions anymore)

I much prefer descriptive names - I think they make things feel more natural and intuitive :slight_smile:

Components is an excellent name imo :003:

Sometimes other names work well due to specific reasons, and usually when other benefits override going for a descriptive name (eg the link between Ruby and Ruby Gems still makes you feel Gems are something that belong to or related to Ruby, but also that they are something ‘great’.)

Well, me too, but sometimes that’s just too hard to bother with. But as I said, I don’t even mind about calling them applications, whatever. Changing it to components for me would be the same, maybe a little bit better descriptive. :man_shrugging:

Well, then maybe all we have to do is invite some very creative people to come up with ‘great’ names and be happy! :joy:

There are two features behind umbrella projects:

  1. Organizing multiple applications in the same repository (you called it poncho but it really is known as the mono-repo pattern)
  2. Allow those applications to run under the same config + deps

The first goal is way more important than the second. If people are using mono-repo, then mission accomplished.

The second feature is a convenience. If it fits your workflow, great, otherwise nuke the umbrella and use path dependencies. This is by design. To the point there are no features specific to umbrellas in Mix on how dependencies are handled. Everything is built on top of path dependencies exactly because we should be allowed to drop umbrellas and fallback to path dependencies.

We had this discussion in the past but in a nutshell, you are supposed to grow out of the built-in generators and upgrade at least to mix --umbrella. :slight_smile:

It is meant to be a journey. If we started everybody at the end of the road, then most people would end-up confused and wondering: how did I get here? Do we really need all of this?


Naming is hard and very subjective. Personally, I’m not sure I like Components as a replacement term for Applications. I think Component is an overloaded term in the front-end space (and programming in general), and I also feel it’s kind of a static term better suited within the context of an Application. Application also doesn’t feel perfectly right, but works better than Components to suggest it’s a more active actor rather than static resource, with the added benefit of familiarity.

I think Service is also good term for this, but maybe a bit narrow. Service in my head also feels more like a resource, or a stateless entity rather than in Elixir’s domain where things can be a lot more than just stateless.

An Elixir Application is sort of different than the typical Applications definition; our go to terms don’t fit very well due to Elixir/Erlang’s multi-faceted nature of being stateless, stateful, composable, and natively interactive in ways Application doesn’t hint at very well. I still think Application is the best term because I don’t really have any internal qualms with the idea and terminology of composable applications.

1 Like

:purple_heart::green_heart::blue_heart::yellow_heart: Thanks for that!!! This made Elixir really fun and easy language to learn! But come on! You should not give your secret sauce that easily! :joy:


Components sounds entirely wrong to replace Applications because Applications in OTP are singular and the word Components makes me think something that is instanceable many times. If Application were to be renamed then I’d think Daemon would be more accurate (OTP does follow the OS-style conventions after all).


To me, an ‘application’ is the whole thing - the finished product - and the application can be made up of many components.

To me a component is literally just that - part of a greater whole.

So for instance I could have a social networking application, which has a registration component, a profile component, a messaging component, a reporting component, etc. Each component could also be made up of smaller components.

I love the idea of building apps as a series of components in this sense :slight_smile:

I also love how Umbrella apps were ahead of their time :003: and how Dave is taking the idea to the next level :023: (I’m just waiting for him to do his next course to fill in all the remaining blanks :lol:).


I might make myself some time and submit a PR for mix --minimal, which would generate even less boilerplate :wink:

(didn’t know about the umbrella option, but I still will stay on the path of path dependencies for now. So far, they seem less confusing to me. And yes, it’s extremely simple to move between both models; one of the reasons I keep liking Elixir is that moving stuff around is so easy)


I just had another idea: what if instead of trying to get a name that fits better than application to all applications purposes, we classify the different purposes into separate things? Like using the term library for applications with no process started, and daemon for the applications with supervisors. @OvermindDL1 I really liked daemon BTW! :slight_smile:

Also, the common name for both in my opinion could be a project, the only generic name I see that could fit for both situations. :wink:

If following the OS style, Applications would be Daemons, random Supervisors would be, well, still Supervisors, Processes would be, well, also Processes… The only thing that does not match fairly directly is just Application to Daemon, but still, Application is fine enough, so I don’t see the point in renaming anything personally. ^.^;


Here is Dave’s talk from Empex where he talks about his “components”. You might want to sit down for this one :grinning:


Loved it!!! :purple_heart:

Personally I prefer the word ‘application’ instead of ‘assembly’ but I can certainly live with Assembly as it adequately expresses the idea of what it is; the assembled Components (and Libraries).

I know I’ve said it before, but I think building apps as a series of components feels incredibly right, and when I look at the reaction of others (in Dave’s course thread as well as the various other threads discussing Dave’s ideas) I think could well be one of Elixir’s ‘killer’ features. It really does excite me that much and I genuinely believe many others, who like me, having been searching for a better way of developing applications, will feel the same.

I reckon that when word gets out that Elixir promotes and makes what is, in my mind, the Replaceable Component Architecture astonishingly easy, we’ll see the next wave of Elixir users in droves :003:


I wish this was talk 1 of a multi-part series (with many more parts available now). I want to see what Dave considers “right” demonstrated, over and over, with before and after examples. A few example apps showing the “new way”. And a mix task that I can use to play with this new idea.

I’m interested but a bit frustrated that a lot of well-intentioned bile was followed up with a couple slides that showed some code that might work in a GitHub repo somewhere. I didn’t see the links in the presentation. I don’t see them as part of the YouTube description or comments. I don’t know where to go from here. Feels like he ran out of time just as he was getting to the interesting bits.


His course is an excellent place to start imo :slight_smile:

I can’t wait for his next course :003:


I love this course. I need to revisit it. But if you’re going to try and change the world, these ideas can’t be behind a paywall. Or at least, can’t only or predominantly live behind a paywall.

It might be nice to for Dave to spin up a site for these ideas, using these ideas. Dog food the whole concept by coding, assembling, and deploying the site using this methodology. Then GitHub the whole thing. There will still be plenty of money to be made on additional hand holding (training/books).


Actually, the course doesn’t go into the stuff in the empex talk-that stuff is just experimental now.

I will be making videos and blog posts about these ideas once things settle down.



When is your next course going public?