Hello everyone. So I just got done reading all of the introduction to Elixir and working through the basics of the language. I am not new to functional programming, I wrote scala for a year Scala in the past and used some F# as well. Elixir will be my first dynamic functional language, don’t see that as being a huge issue though. I have no problems with the basic fundamentals of recursion, pipelines, etc. What I am looking to get most acquainted with is the idioms in elixir for managing state, concurrency, architecture, OTP and all of the things I need to build a production-ready app with Phoenix.
I have purchased a few books Programming Elixir 1.6, Programming Phoenix 1.4, and Meta-Programming in Elixir. I really like to know everything that’s going on underneath the hood when using a framework and I Have about 10 days of free time to really get up to speed with the language and ecosystem before I embark upon beginning to build a side project with phoenix.
I was about to start reading Programming Elixir, but I see a lot of posts here about the course elixir for programmers. For those who have read the book and done the course, which one is do you consider to be more in-depth and likely to get me up to speed faster?
Looks like you’ve already got some fantastic books
I agree with Peer about adding Elixir In Action and Programming Ecto - they are fantastic books and EIA in particular will help you in getting your head around processes and how they work in things like genservers/supervisors etc.
Dave’s course is more about architecting software - it shows you how you could use Elixir and Phoenix.
To be honest, it’s a practice that I have followed for every language I have ever learned. I usually give myself ( at most ) a week to get up to speed with the language and then I like to start building.
I’ve never found myself able to fully grasp a concept just by reading or watching videos. I have to learn from the standpoint of actually getting my hands dirty with a project. I’m more of the learn as I go / learn by doing type.
The only reason I’m even giving myself 2 weeks ( I’ve been learning for 3 days now ) is because I need to get up to speed with Phoenix on top of elixir.
I think there is the expectation that there will be some learning in parallel after the side project has already started.
Aside: To some degree you can start with Phoenix and Ecto before understanding OTP or even processes as long as you have the language basics and are comfortable immutability by default. Though in the long run BEAM languages are primarily concurrent programming languages first and only functional programming languages for pragmatic reasons.
I’ve never found myself able to fully grasp a concept just by reading or watching videos.
I tend to agree which is why I have the habit of working through most books rather than just reading them - though that also tends to be slower. I’d say that both Elixir in Action and Programming Phoenix 1.4 can be approached that way as well as at least the first half of Programming Ecto.
That said you have to do what works for you.
Personally I found that the documentation became much easier to understand once I completed those books. This is not meant as criticism of the documentation - but package documentation will tend towards communication efficiency, limiting possible duplication by assuming the reader’s familarity of certain concepts which are already explained elsewhere. Books (or courses) can cover concepts that newcomers may not be familiar with in a much more organized, guided fashion.
I have no problem with immutability by default ( actually prefer it ), or the functional aspects of the language. It’s the concurrency model, gen_server, supervisors, and all the idioms that come with using it that I want to get a good grasp on. I also want to learn a little erlang, and read the meta programming book before jumping into phoenix and ecto as it seems like they both rely heavily on the use of macros, so I want to know how that actually works.
Thanks for the link as well. Very interesting read.
It sounds like you have a lot of experience. If you’re looking for a mini project to test your understanding of OTP idioms instead of just plain old FP, I would say implement a tcp daemon. Maybe even http from scratch (or something more exotic if you have domain specific knowledge and want to contrib to the community).
I’d say first do client (which will require basic otp genserver stuff and how to interact this with erlang tcp module) then do daemon/server. Then supervise them - and write tests where you kill the daemon, server, and client genserver processes and watch the system self-heal. That accomplishment alone feels really great. If you have time also do process pools (I haven’t done that myself, yet).