For anyone curious about Phoenix and Elixir, I can sincerely recommend the following resources to get you started:
- Programming Phoenix by Chris McCord, Bruce Tate, and José Valim [1]
- The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao [2]
- Elixir in Action by Saša Jurić [3]
Phoenix initially attracted me to Elixir, I've stuck around for that and the OTP platform: pattern matching, process based concurrency (actor model), supervision, immutability, macros, and more.
"Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system." – Dave Thomas
I just got it a few days ago and I'm about 30% into the first book. What I can say so far is that the author's approach resonates really well with me. Going through the book feels like sitting next to a colleague, who is introducing you to Phoenix and is really knowledgeable in the topic. The book is full of interesting tidbits and explanations about Phoenix internals without getting in the way. I also appreciate the TDD approach including both acceptance and unit testing. The most important thing for me though, is how Shankar condensed teaching Elixir into a single chapter. I have previously tried to study Elixir a few times with the intention of eventually getting into Phoenix but I always got overwhelmed by the OTP material. I didn't want to make the mistake of trying to learn Rails before being comfortable with Ruby again so I put off on learning Phoenix altogether. What Shankar has done is to dedicate one chapter to teach just enough Elixir for you to get started. This was perfect for what I needed and it was reassuring knowing exactly how much (or little) Elixir you need to know before diving into Phoenix.
If you have previous experience in another MVC framework and are interested in Phoenix I highly recommend this series (at least based on what I've read so far).
I should note that the current version of the book is targeting Phoenix v1.3.0-rc.2. Although Shankar has already made an announcement with the intention to update the book soon after the officially 1.3.0 release.
> If you have previous experience in another MVC framework and are interested in Phoenix I highly recommend this series (at least based on what I've read so far).
Do you need Elixir experiences too?
I've done MVC and have some functional experiences.
I've seen this book but wasn't sure if it was for me and decided to do exercism's elixir exercises before buying this book.
I think you should be fine, especially considering you have some functional experience. In the second chapter of the book, the author goes over Elixir from scratch. By the end of the chapter you should have a working knowledge of the language. Even beyond this chapter, the author takes time to dissect and explain the more complicated looking code. It really does feel quite approachable to anyone with a few years of programming experience.
From the web site: "Create a mini-Phoenix framework using Elixir and Cowboy. What can be the best way to understand Phoenix than to create it yourself."
Garuda, I'm sure after googling you found the Wikipedia entry for it. It is just a play on words since Garuda, like Phoenix, is a type of mythical bird.
Tomte, "Garuda" is not a random title. As you and others have guessed it, Garuda is a mythical bird in Indian mythology just like Phoenix being a mythical bird in Greek mythology. Since the book is about "Demystify Phoenix Internals & Rebuild Phoenix Clone", I have named it as Garuda.
I agree with you, I could have explained the book's content and its title a bit more clearer on my website. I will do it sometime soon.
You build you a simple HTTP server using Elixir and learn a lot of the core language and architecture choices when writing Elixir code. It doesn't pester you with this is an int, this is a string. You just start building this HTTP server out and learn about Elixir along the way.
+1 on "The Little Elixir & OTP Guidebook". It's a generally good introduction to OTP, though the book has a lot more errors than I'm used to seeing (their github code differs without explanation from the code in the book at times, and sometimes one or the other won't run successfully).
Hey, are there already some tutorials / books for Phoenix 1.3? I found this [1], but it will be released in late december 2017. Any ideas / recommendations for the Phoenix 1.3? Folder structure and models (schemas) got changed quite a bit.
Just want to point out that Records are still part of the standard library, and can be important for integrating with Erlang code using records which you need to work with. Even though they are avoided in Elixir, because structs are better in every way, they are still alive and well in Erlang.
We’ve been using Phoenix at my company in production for over a year now. So far the experience has been overwhelmingly positive, our team have totally come round to its adoption, our server costs have come down and our response times have gone down also.
Coming from Rails, the ecosystem isn’t quite there yet, but it is far more mature than rails’ was this early on.
The hardest thing for us has been deployment, but we’ve solved that internally, including giving back by building exrm_deb (it works with distillery too!) to compile the entire project into a Debian package.
If you haven’t already looked at Phoenix (and Ecto!) give it a try :)
As a .NET developer by day, I'm curious what you like about Elixir over C#/.NET? I have a copy of Elixir in Action on my nightstand, I just haven't had a chance to crack it open yet.
I wouldn't say I like things over C#/.NET (I love C# and use it for mobile/desktop devel, but I've never used it for web).. but I'll list some things I like about Elixir:
Erlang's concurrency model is amazing. It's like having micro-microservices running inside your virtual machine. And you can distribute across nodes. Nothing else really has this kind of thing.
Pattern matching is beautiful and it's easy to use. Other languages have this too, so it's not like this is unique. This is one of my favorite things though; you can destructure things, you can pattern match inside a function using case, and you can pattern match on functions themselves like:
That's basically the equivalent of having a single say() function that then does a switch/case on the input.
And a more recent addition to the language is "with". This is fantastic, it's one of my favorite things now. Usually you might have code that sets a variable from something, checks to make sure it's valid, sets another variable, checks to make sure it's valid, etc, etc... until finally you're function is ready to actually perform its purpose. Any of those checks might cause it to exit early or to switch paths. So Elixir has this "with" feature that looks sort of like this:
I believe these are referred to Railway-Oriented Programming. I've seen several other examples for Elixir (incl. ones using macros), but by far this is the 'cleanest' syntax :)
Here's a similar construct in Scala:
(for {
user <- currentUser(...)
group <- groups.fetchForUser(...)
friend <- friendships.fetchFriend(...)
member <- groups.addMember(...)
} yield {
render(...)
}).recover {
case e: Exception -> ...
}
The Scala example, yes... The Elixir one? Is it actually a Monad? I figure it's simply destructuring + pattern matching (against the value of the first tuple value, :ok or :error atom).
To expand a bit more, it's not like Scala's `Either[T, U]` where we're limited to a pair of types, I think you can return other atom values (but use :ok and :error) as a convention.
Also, there is an Elixir library I'm using that's a closer in spirit to Scala's for-comprehension called `monadex`. Example below:
result = success(comment_params)
~>> fn p -> link_reply_to_id(p) end
~>> fn p -> create_changeset(p) end
~>> fn cs -> assert_changeset(cs) end
~>> fn cs -> insert_changeset(cs) end
Pattern Matching makes it easy to write small, understandable code
The Concurrency Model is simple to the point where creating a whole pubsub system to handle events, push out notifications, and handles backpressure can be done in < 100 lines with no additional datastores or frameworks.
Finally the pipe operator is like C#'s LINQ statements but with so much more power and flexibility, hard to explain but I highly recommend cracking open that book on your nightstand!
The directory reorganization is a good sign that Elixir/Phoenix are not simply rehashing Ruby/Rails for the sake of popularity but are willing to prioritize what makes the most sense for this particular language - and asking how they can improve upon what already exists.
I recently ported my app from 1.2->1.3 and moving away from Models to Contexts/Data was a simple transition that makes a lot of sense.
The `data` files (aka your new models) are basically where the schema for your model lives and the `context` (your models API) is the interface for your data.
For example when building a blog:
Instead of having User, Session, Post, and Comment models which contains your DB schema, business logic, and interfaces for getting/setting data all models directory ala Rails:
And in your data file `lib/blog_app/blog/post.ex` for example, you'd keep just your schema defining the fields like "title, permalink, body, etc" and code to handle validations and virtual attributes.
Then in your context file `lib/blog_app/blog/blog.ex` you define the API that access your data. So from your controller instead of calling:
Phoenix is great! I only wish there was one recommended way for authentication and authorization - there are so many [1] different libraries that I got stuck in researching the options - I am confused, do not know which one to use. What is your preferred way? I would like to avoid to implement every little detail on my own - to get security done right was the main reason for me using open source libraries.
It would be great if there was one official way to make it easier to implement app security with the framework. I feel that this is the only missing part in phoenix - but it is a very important one.
BTW: does anybody know some tool that generates a phoenix api from a json-schema? Thanks!
The beautiful thing about Phoenix framework is that there is no "one-true way" to do things. Rails is omakase, Phoenix is not, and that's a good thing.
You want the whole enchilada? Use Guardian.
Need oauth? Use ueberauth.
Just want email and password? Use comeonin to hash your password.
It's liberating to know exactly how your system works and that it's not hidden behind some magical blackbox like Devise.
A blackbox is not what I was asking for. I would be happy to find the features you described (and many more) in one (extensible) place like e.g. Phoenix.Security.
The problem with that approach is that imagine if Phoenix had a Phoenix.Security.sign_in function. How do you want to sign in?
With a cookie?
With a server-side session?
With a database session?
With an authentication token GET params?
With an authentication token in the header?
You make the choices for your specific use case and implement them using laser-focused, great packages. One system I built authenticates with an `authenticationToken` GET params, I look for that in a Plug, then assign the current_user to the conn object.
For me the sweet spot is somewhere in between. If it just shipped with a decent auth module that would work for 90% of people, but that could also be easily replaced or extended if needed, that would be the best of both worlds.
Even rails doesn't ship with an auth module though. Lots of people use Devise and there is an equivalent for Elixir (Coherence)...but shipping with auth built in is an exploit waiting to happen IMO.
has_secure_password is not an "auth module". That's simply a handy function to handle a password attribute... which an actual auth module can make use of if it desired.
I've been using Joken for that (JWT), just finished writing up some code that integrates with Auth0 and pulls in the signing certificate from the auth0 domain (.well-known/jwks.json).
If you're coming from a Rails background, you'll find Coherence[1] similar to Devise.
However, I was recently in need of implementing authentication for more than two models (Buyer, Seller) and that's where I hit a roadblock with these Devise-like libraries. Just by chance I found a really good, well designed library which I use in production as of now. The author is also the author of many other famous libraries in Phoenix-verse (Comeonin, for example). The library is called Phauxth. Check it out:
I agree with you. Most of the web apps required authentication with email + social(google, fb twitter, github). In most of the rails app people would be using Devise + omniauth and these both works seamlessly and very easy to integrate.
As of now there are no libraries available to implement above functionality easily for Phoenix framework. For me also this is one of the main reason to go ahead with Elixir + Phoenix
I'm spending all my free time with Phoenix. I come from a Rails, Laravel, Django and a bit of .NET Core background. So far I am extremely impressed. I'm surprised it has not been adopted by that many folks in production.
You'll have a phase of disorientation where you'll be wishing you had x feature in Django and the reverse where you'll wish you had y feature in Phoenix/Elixir.
The thing I really miss from Django is the admin scaffolding. Phoenix just isn't there. In practice, you could continue to use Django as a front-end.
I moved away from Django when the recurring question of "this is neat, but how do I make it keep going no matter what?"
The problem is that I was/still am a rookie of a programmer. I could not wrap my head around async in Python. I just wasn't getting it. I had a nagging sense that it was going to fail in the middle of the night and there was nothing I could do about it.
So, enter Elixir, which actually has a syntax that is kind of close to Python. It made immediate sense. If you want to do something that can cause the program to fail, do it in a process and send a message back with the result. If the program spawning the process fails, the supervisor will restart it!
Sorry - back to your question - and this will probably disatisfy you, but the answer is that everything was neat. It was just simple CRUD stuff, but doing it in Python didn't feel "robust" enough.
I'm fully aware that my reasons are superficial, but the way Elixir works has made me way more confident as a programmer.
This isn't your fault. Python doesn't get the asynchronous stuff particularly right, nor does it make it as straightforward as it should. I've moved to Elixir and one of my employers has moved to Go as a direct result of Python's concurrency model (and the hilariously needless and recondite primitives attached). Your reasons aren't particularly superficial; I'd pick the Actor model over systemd and uWSGI for anything critical!
As a Ruby/Rails guy, here's my experience(summary):
I came to Ruby from Java, I wrote Ruby code like Java code at the start, it runs, but it is bad, once I really learned to write Ruby code it became a billion times better.
Same thing happened to Elixir, my first few lines of Elixir were very similar to Ruby, similar syntax makes this possible, but I missed the real gains from Elixir this way.
There are quite a few functional programming concepts to learn, but once I finally clicked what pattern matching was all about Elixir programming went from enjoyable to amazing, if you can work functional programming concepts your way you can do a lot.
That said, don't worry about it unless it is critical for your job, do your code, once all the concepts click in it gets way better, spend some time with pure Elixir, it pays off just as much as it pays to a Rails developer to understand what Ruby is all about.
Phoenix works within existing Elixir constructs like macros and modules, so it keeps a lot of the nice interfaces of Rails without the magic, how things work is pretty straightforward.
It is worth stating that the way Erlang/Elixir manage processes is completely different than most other languages and that has to be grokked at some point. Thankfully the framework abstracts a lot of that.
The Elixir and Phoenix docs are also pretty good. They're not Django-level (what is), but they're good.
Phoenix 1.3.0 really helps you understand that you are just making an Elixir app with some additional features. I don't think there is as much "magic" as Rails.
There's almost no magic in Phoenix, it's modular from the start and is really just a collection of libraries held together by some mix tasks to help you structure stuff.
Phoenix is much more straightforward and explicit but macros are used a lot in both Phoenix and the Elixir standard library. I think most of the macros are fine but opinions vary widely on that.
I tend to think of "magic" as meaning fragile, indirect coupling; for example "magic numbers" at the start of files, which are only meaningful if the consuming application has a corresponding pattern in its database.
Or sets of things which only work if given in a particular order. Or unrelated functionalities which interfere with each other due to implementation details. And so on.
In other words, leaky abstractions where thinking in terms of the concept has so many edge cases that it's easier to think in terms of the implementation instead. Or conventions which can only be used via memorisation, trial and error, stack overflow and reading the source (often this is due to shoehorning things into language models which aren't amenable; e.g. all of the things aspect oriented programming tries to do)
Go into it with the attitude of 'deferal of gratitude'. In other words it might look painful for a while but when various things click you get your holy s moments and you'll never go back. I've worked in a lot of java, php, python, c# etc frameworks and there are very specific reasons this is near always better long term. A lot of it comes back to elixir simply solving the correct problems. Learn elixir using the elixir lang site guides and then jump into phoenix using their official guides. Eventually you'll experience the upsides and versatility
By correct you mean that Elixir solves problems differently than java, php, python, etc. and you found this more appealing over time, which may or may not be the case for someone else.
Or are you making a stronger claim that language X is better than Y, at least when it comes to web dev?
No I don't mean it in a way that is subjective. It does depend on person to person because of factors in their knowledge and situation, history etc etc, but elixir lives in a world that the others don't. Making a language that plays on the erlang vm and has complete access to OTP was a good solve. Other languages haven't been able to replicate OTP despite attempts (and they likely won't). It's not better for everything and the language isn't somehow obviuosly better, it just solved the right problem if you want easy web scale that doesn't do things like drop connections when you release or have a difficult concurrency model. Functional programming is a grind at first but it's a good fit for this world and elixir is more accessable day to day than erlang. I have way more experience with PHP but there are limitations there that can't be solved. So I would say that both your points apply, I am making the claim that X is better than Y because of core value reasons, but that doesn't mean that economically other languages don't make sense for web programming. I still make new projects in PHP and Python because of existing infra at work and others that can't/won't learn elixir and co. We'll just be making something slightly inferior and not be building tools for a more pleasant future, but it still makes money for the biz and isn't terrible
I've used both and honestly it probably wouldn't change much. Unless you're building an application that deals with tons of persistent connections and websockets there aren't really that many advantages. The Python ecosystem is also much, much bigger than the Erlang and Elixir ecosystem and it has far more mature libraries.
If you really want to learn a functional programming language I'd strongly suggest looking at Haskell, Ocaml or F#. Functional programming only really starts to shine with a good static type system and dialyzer simply doesn't cut it.
The difference between Elixir/Erlang and a statically typed functional language is that it's built for distribution.
In a distributed system where machines register on a cluster and messages are passed constantly across isolated heaps, processes and entire machines transparently all of the assumed protections of a static type system break down. You can't enforce static types across a cluster anymore than you can across a JSON requests to somebody else's API without a lot of extra overhead.
Static types are essentially contracts and in order to enforce a contract like that on a cluster of different machines that would mean you'd have to exchange contracts everytime a new machine joined the cluster...for all modules and functions...with every machine on the cluster. And then you have to determine how to handle contract violations.
Clustered message passing operates more like request routing in that regard. Send to this machine, to this module, to a function named this, with this arity, that matches this pattern.
The Elixir gradual typing approach balances this reality extremely well in my opinion. You get type checking if you want it and can specify it in more detail...but it won't promise something that it can't guarantee across the cluster, across deploys and across changes.
I beg to differ. FP with Clojure is pure joy. Spec, which is due out soon with 1.9, is also the next best thing to static typing. Some would even say it's better.
>> I'm surprised it has not been adopted by that many folks in production.
I'm surprised that it's used in production at all. It's based on a new language that is years behind all the others in terms of available third-party libraries and modules.
Does the language lack some maturity? Sure. But you don't have to use pure elixir for everything. You can leverage most Erlang packages. Phoenix is hosted on Cowboy[0] which is a mature, battle tested web server written in Erlang.
Really excited to see this out. I've been learning Elixir and Phoenix with the 1.3rc and have really been enjoying it!
I'm a fan of Contexts myself as that is typically how I architect apps on mobile as well. I like having everything separated more explicitly and testable individually and Contexts seem to promote that in a really nice way.
I'm just a bystander reading about erlang and elixir for awhile. Did web dev in php and a little bit of nodejs.
But I think what you guys doing are great. I'm glad Elixir and Phoenix came about it really helps drive the language into a field (web dev) and get people to notice.
And that one implementation of figuring out how people is log off or not that is in Phoenix was really sweet when you presented it.
Just me personally, I probably wouldn't do it in anything else... Not that there aren't some other good options out there depending on your background. I just prefer Elixir, I know it scales in both maintenance and performance (the former being the more difficult goal in my mind) I think the market is growing such that finding engineers who a) have experience, or b) want experience with it, won't be a real problem. I can tackle software and hardware problems alike, there are good options for integrating native code when performance counts, and in general I consider it to be the safest option available to me.
I use it for my own small startup + my work uses it as well. Couldn't recommend it hard enough. Elixir 1.5 (just released) improves Developer Experience and makes things a little easier to debug.
Highly recommended, but as always ignore the hype/recommendations and do your own research.
I actually love the domain driven work done in this release. I think it was a bold move from the team and breaks them even further away from Rails on EVM that people tend to think.
I have been bit so many times with trying to figure out where to put things like authentication/registration in a traditional MVC rails like app.
I've always been intrigued by Phoenix/Elixir but I was worried it may just be a fad. Seems like it's had solid growth over the last couple years though, so I may end up diving into it over the weekend.
We are using Elixir and Phoenix. Its amazbalz. The properties of the erlang VM (100k processes, individually garbage collected etc) are going to make it a killer platform. (edited)
YMMV on protocols, just depends on what you're looking for. Most reasonable protocols you'd want are supportable. The only time I've been left scratching my head was trying to get the VM running on a SOCKS proxy, which I think probably speaks more to my lack of familiarity with doing so (though in the source of this I found that the native SOCKS libraries were removed some time ago.
We're using it at a client as a kind of nexus of all our legacy systems, in fact.
I use Phoenix with all my newer projects. The performance is stellar. I single-handedly was able to create what many startups out there have built with 100s of thousands of engineers[1] in a short period of time. This may be possible with Rails too, but then, I found a lot of things are much more convenient to get done in Phoenix than in Rails - For example, Contexts (nested models), Routes, etc.
When I started with Phoenix I was anxious that the experience was going to be just like when I first tried out Play/Scala, but no. To my surprise, my experience was fantastic. Truly, this framework allows you to focus on your business problems rather than fighting with configurations/conventions.
One of the best decisions the team has made is introducing the concept of contexts from DDD[2]. Initially, I was pretty confused, but now, I simply cannot imagine myself going back once that I've understood it. It's basically breaking down your business into smaller tiny modules, like I've done in [1]. The other thing I love about Phoenix is the concept of umbrella applications. I'm not sure if Rails has an equivalent, but I think this alone is worth exploring Phoenix for.
I don't even have micro-services in my architecture yet, but because of these patterns, I'll be able to break out and scale my application if I require to, in the future.
Phoenix has proven to me that it can not only scale performance-wise, but also architecture-wise. Last time I tried developing [1], it was in PHP and I had to hire 5 devs to get it done..6 months later and we still weren't done. However, in just a matter of weeks, I was able to finish a complete working prototype of this mammoth application, with UI and frontend. As for my production setup, I use Docker + AppEngine (using a custom VM) and it has served me really well. The performance is top notch and everything works so flawless.
As for the language itself, I really love Elixir. I simply cannot imagine going back. It really forces you to think differently about your code. Last time I tried to learn a functional language, it was Scala - also a beautiful language on top of the JVM. But, the problem is, it's so academic in the sense that even a good book on scala had 400+ pages. Some of them had 700+ pages. But Elixir isn't like that, you can pick up the language in a matter of weeks (YMMV, it took me 2) AND build a project in no time.
For Elixir, if you're coming from a Ruby background, you'll be able to pick it up fairly easy. However, you will find it challenging when you hit a situation where you would have used a traditional for loop, but in Elixir, you would be forced to re-architect your code. And that's a good thing.
Interesting. I've been trying to decide which language to learn next. Between Scala, elixir, and haskell at the moment. Was leaning Scala, but all the praise here is starting to convince me to go elixir. What problems did you run into with Scala?
In Scala, there are many ways to write a function. I wish I can share some code snippets, but, I'll just summarize for the sake of simplicity:
1) Functions have different forms and even nomenclature based on how many parameters they accept, how they are represented, etc.
2) Scala still has OO, which means it needs to carry a lot of baggage. The breadth of Scala's nomenclature combined with OO will take you a long way to learn the language.
3) Scala still runs on JVM which means you need to learn some of the JVM concepts if you'll be using it in prod. If you're from a Rails background, this is completely a new arena, because this is usually the Java guys' arena.
4) I wanted to be able to simply open up the source code and be able to understand what's happening. This was possible in Ruby/Rails, and ultra easy to do in Phoenix/Elixir, but painful in Play/Scala. IF you open up the source code of a Play! framework project, there's code so succinct that you would need to be strong with the language's understanding to get the full picture. Case class, implicit, etc., just to cite a few. In Elixir/Phoenix, it's just modules and it's just simple, yet elegant.
5) That being said, it's still good to learn Scala because there are tons of libraries out there with special use cases which you can use Scala for - It's still a good strongly typed language to build a robust project on.
IF I remember correctly, David Pollak mentioned in his book that he'd written an app in Scala that ran for years without any problems.
As for Haskell, I read this somewhere - "Haskell is nice and all, but it's no Erlang."
Since Erlang also has a bit of a learning curve, the next best alternative is Elixir.
P.S, - languages should be chosen based on one's own philosophy and in this case, Elixir strongly resonates with my own philosophy and all this is just my own opinion on why I chose it :)
> I wanted to be able to simply open up the source code and be able to understand what's happening. This was possible in Ruby/Rails, and ultra easy to do in Phoenix/Elixir
While it is possible to look at source code in Ruby/Rails, in practice for me (even after a few years of production ruby experience) it was extremely painful to look at any number of libraries due to the amount of redirection and implicit state, and monkey patching. But Elixir has (almost always) been VERY easy to follow, sometimes the code is just so simple.
It's truly amazing when you see the numbers yourself, as Elixir/Phoenix produces some wicked TTFB(time to first byte) speed and concurrent performances you can't get from other languages.
I wouldn't be surprised to see one elixir server replacing 5x - 10x servers.
Me neither. Devops is a hat I wasn't interested in wearing.
Which is why I tried Gigalixir[1] and never looked back. It's sort of like Heroku for Phoenix/Elixir, but without the daily restarts and with hot upgrades and the ability to run a BEAM cluster. Jes (owner) has been super responsive and deploys are trivial... just like I like it.
Also got Postgres running in google cloud (a new offering!) and that's worked great as well.
Sparkpost for an email API and Timber.io for cloud logs have also been stellar. Sweet dashboards.
I also work on a number of side projects with coworkers and we host those in Heroku. Can't really speak to how well that'd work if they were more than just side projects, but it works for us.
I'll prefix my comment by saying I'm someone who is more on the sysadmin side of the scale of things. My code isn't pretty, but it generally works well enough to get the job done. I'm learning (probably the most important thing, I guess).
Contexts are one of things that I felt the same about. Until I tried really using them, rather than stressing over whether or not I was using them properly.
I made the mistake of trying to think of them as microservices, which bogged me down and for my purposes was complete overkill. I've now reached a kind of happy medium, which I've realised that I really should have already been using. I've kinda realised I suck at api design. And for that I'm very thankful to the phoenix team, because it feels like I'm learning.
Contexts are in practice pretty nice, and you don't have to use them. I've found that in my own work with 1.3.rc.*, the contexts describe an area of the system and help enforce some separation of concerns. That said, you're free to build everything in one context.
I have an example where context works well for me.
I have built an app[0], the app allow user to submit links, either using our web ui or via a bot.
When using web ui, they have to login, hence we associate the links with that user. The bot is different, everyone submit via the post share the same `Bot` account.
In other words, the process of inserting a link from web ui or via bot is a bit different. Without context, I would use different module or some branch code to distinct between them. I think context solves that nicely for me.
Contexts are just the default now. Nothing is preventing you from doing things the old way, or from using them in 1.2 without upgrading. If you can think of a better architecture that doesn't involve contexts, then that should absolutely be what you're doing.
But if you don't, that's cool too. There are mix tasks for using the older style generators and mix tasks for the newer context style generators. Use whichever you prefer.
I wouldn't say "better". Like any other framework, many things have to be weighed. In the case of F#, it's a fantastic language with a fantastic runtime. It is still "windows only"* for the moment though. Akka (and yes, I realize that you mentioned .NET) is also very good in its varieties. Scala being one of the ones that I've actually used. I believe where the sweet-spot is for Elixir, in general is that Rubyists will feel mostly at home. The language itself is just very, very nice. Phoenix continues this by copying some of the nice ideas from Rails. But again, It's not better than the language and tech that you mentioned, but it fits a certain swath of developers. I wouldn't recommend someone who is well versed in F# with Akka.NET drop what they're doing to migrate.
*Yes, I'm aware of Mono, but I've been completely unhappy with my experience using it.
- Programming Phoenix by Chris McCord, Bruce Tate, and José Valim [1]
- The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao [2]
- Elixir in Action by Saša Jurić [3]
Phoenix initially attracted me to Elixir, I've stuck around for that and the OTP platform: pattern matching, process based concurrency (actor model), supervision, immutability, macros, and more.
"Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system." – Dave Thomas
[1] https://startlearningelixir.com/r/programming-phoenix
[2] https://startlearningelixir.com/r/the-little-elixir-and-otp-...
[3] https://startlearningelixir.com/r/elixir-in-action