That’s a fair take, @dimitarvp . The last time I felt this way was more than a decade ago when I became a Rubyist. I appreciated how it was optimized for programmer happiness. I see that in the Elixir ecosystem now
On a personal note, my goal is to build stuff and be able to provide for my family, and I want the option to be able to do that as a solo dev or on a small team. Elixir/OTP + Phoenix (and maybe Ash) feels like a great potential fit for that.
As I’m going through PragDave’s course I’m curious about his opinions regarding project structure vis-à-vis community standards or what’s considered idiomatic Elixir.
For example, in the “Let’s start coding > Start coding” section, there’s this bit:
I personally put the logic part of my code into a directory called lib/impl; most in the community instead use lib/hangman (or whatever your application is called) for all their application’s files.
You’ll start to see the benefits of having split directories when we look at processes.
I guess I’ll just have to wait and see about the benefits of having split directories, but I’m also curious about the pros and cons versus what “most in the community instead use”.
For all my 24 years of career, I never once found a good dir + file structure I was happy with. Nothing quite clicked. I think the problem is that many relationships between entities are forming a graph whereas the filesystems are trees.
But I did find a lot of super convinced advocates of a number of strange conventions i.e. order/read.ex and order/delete.ex… one action per file! Madness. Though I’ll admit it makes it a touch easier for fuzzy searching a filename or file contents. This approach gets a few points more in marks.
IMO the Unison language is the only one who gets this right; content-addressed code. In the meantime, before all PLs finally reailze its the 21st century, projects could become f.ex. a singular SQLite database indexed by a number of fields i.e. domain, namespace, implemened behaviours / protocols, app code vs. test code, and such. Also add arbitrary tags and propose a few hundred standard ones.
The whole thing of dir → file(s) → module(s) → function(s) is hugely outdated and has been for at least 20 years.
But again, I am not super against entity/action.ex. It makes fuzzy searching a little easier. Though I never had problems when doing fuzzy search for f.ex. def list_ (assuming using normal Phoenix generators) and finding what I need in literal two seconds.
Hey,
Like you, I too am new to Elixir and am learning. I will preface by saying that I think we learn (or chose to learn) quite differently, so this recommendation may or may not be great for you. It appears to me that you are methodically creating a learning plan and working through it (which is awesome). I, on the other hand, prefer to just jump in and try stuff. One of the first things I did was to build a GenServer (barely understood what I was doing) that kept a tree data structure in memory. In my case, that was a quick sanity check, go/no-go choice on whether to adopt Elixir.
That disclaimer said, I found a series on YouTube of Jose doing the advent of code in 2021 to be very useful for me: https://www.youtube.com/playlist?list=PLNP8vc86_-SOV1ZEvX_q9BLYWL586zWnF. It felt a bit like the good bits of pair programming, wherein I got to experience writing Elixir as if I ‘knew what I was doing’.
For me it helped to see the language being written wholistically, rather than as a series of concepts. For example, rather than learning about cond as part of branching functions and then later learning about pattern matching, they might be demonstrated working together to solve a particular problem.
Anyway, check it out, maybe it will help =).
Welcome to the community. Personally, I would recommend starting with one Elixir book, then one Phoenix book, and then trying to build something immediately after that. Phoenix book in particular will most likely cover testing as well as Ecto, to a reasonable depth. From there, you can use the books to supplement your knowledge.
Don’t get me wrong, I love reading books. But at your level of experience, I think you’d gain a lot more from doing.
Ash has been growing in popularity, but it’s also both not necessary for building things, and is very different than basically everything else in the ecosystem. Good to read if you want to improve your employability. OK to skip for now otherwise.
Thank you for sharing José’s AOC videos – I look forward to checking these out!
I’d hazard a guess that Prag Dave’s course is similar in the sense that it felt a lot like pair programming. It’s probably the least expensive of all the courses I’ve signed up for and I’d also recommend checking it out.
Thanks for the feedback!
When I tackle something new I like to get a comprehensive overview first, and then dig in as necessary. It might be unconventional, but I’ve found that I tend to move faster when I have a good understanding of how all of the pieces fit together. It’s also just a lot more of a satisfying feeling for me 
As for Ash, I have a hunch it’s going to help me build things very quickly. I probably mentioned this somewhere here before, but months before learning about Ash I read Eric Evan’s Domain-Driven Design book, so I kind of feel like stumbling into the Elixir ecosystem, and then “discovering” the Ash Framework, was kismet.
I also really appreciate the declarative nature of the framework; this is one of the many reasons I’ve been going all in with Nix/NixOS.
As for my overall learning journey, I’ve been pretty heads down for the past few weeks. I’m currently about 1/3 of the way through the Pragmatic Studio’s Full-Stack Phoenix course, and have finished their Elixir & OTP course, as well as Prag Dave’s course. I picked up some other resources during Black Friday sales, but I’ll share more about those later.
Before joining the Elixir ecosystem I had a very specific idea of what I wanted to build, but I wasn’t clear on how to build it. I’m still not entirely clear on how to build it, but I’m getting closer every day.
However, before then, I think the next logical step is to build a bunch of little things as quickly as I can. There are just a few more things I want to check off my learning list before I start…