Phoenix LiveView [0] is really exciting to try out in Elixir. I'd recommend building an auto updating dashboard.
I had a micro controller that had various sensors on it that I connected to over a serial port using circuits_uart[1]. I then read the sensor values and displayed them on a LiveView dashboard. Totally pointless but super fun :)
For a fun and complicated Elixir project, you could try building a process pipeline that uses all your CPU cores to crunch some data. Look into Elixir Flow [0], for example, which has a fun guide on counting words in a file.
Elixir & Phoenix work well for web projects. The Phoenix framework is very well built on a solid core; it differs from other frameworks in that it feels more like a library, rather than a monstrosity that forces you to bend your application to its requirements. There's a lot of nice utilities that are easily pluggable and writing "plugs" yourself is rather simple as well. Phoenix has served me well when building microservices, too.
Elixir's biggest deficiency is that it does not have a proper type system. There is a very basic one, but it doesn't really help a whole lot. When working with Elixir, a type system is something that I miss the most. The way that Erlang & Beam VM are built makes it slightly easier to deal with errors at run-time, but catching stupidities at compile-time would still be immensely valuable.
Have you looked at Dialyxir? [1] It makes Elixir feel like a structurally typed language. I use it at work, and it catches a lot of inconsistencies at runtime.
I'll second the Elixir guide and maybe go on to the Phoenix guide for web dev.
I just read enough to get going and then start building, then go back, read more, fix what I built.
But people learn differently. I don't really get through books and I haven't needed courses aside from random examples of how to do some things.
It's a short project in which you create a homemade key/value store application. What's illuminating coming from elsewhere is how much it "just works" across the network and with multiple nodes including grace under failure.
I just started my Elixir journey late last year, and I've been using a combination of Elixir School[0], the Ecto guides[1] and a video course from Pragmatic Studio[2] that I picked up on sale back in December.
The video course was a mixed bag but mostly useful. I am also new to functional programming so it was helpful for getting my head around a new way of planning my code but there were definitely chapters that were painfully basic and slow. So if you're already more advanced, it may not be as useful to you.
That said, they did a good job of introducing certain key Elixir/Erlang concepts by getting you to build functionality "by hand" and then refactoring it into the standard library functionality, so you can understand how it works under the hood, while also learning how to use the built-in library modules in real code.
Elixir has some pretty important concepts around concurrency, state management, and process supervision that are worth exploring in detail before you dive in too deep.
In terms of personal projects, I always try to re-implement an existing project when I tackle a new language. Right now I'm working on a simple scraper/parser that uses a shared worker pool for concurrent post-processing of links scraped by the main thread.
Could you explain a little bit more what you didnt like about the video course. No affiliation but I want to enter this area and I always looking forward to understand what make a course bad/good for a student.
Like I said I think overall the video course was well done, and I'm still glad I took it.
Honestly, I think my gripes are mostly subjective, and this will always be the case with one-size-fits-all training.
Certain aspects that are covered by the course were things I was already quite familiar with, so I was itching to skip ahead. There was nothing wrong with the work itself or the instructors. That stuff was very good.
Yes, it makes sense. I think both their framework courses (Rails/Phoenix) are solid but pretty basic. They have a nice production quality so there is definitively a lot of worth in them.
If you really want to learn Elixir, you should learn enough Erlang prior, to get a better understanding of how Erlang/OTP all fits together. Thus, I would recommend the following structure:
1. Read Joe Armstrong's Book: Programming Erlang to learn the basics and the philosophy behind Erlang from one of its creators. [1]
2. Read Erlang and OTP in Action to learn more about the OTP (Open Telecom Platform), applications and gen_servers (which btw, you will find them all over).
3. Learn Elixir, perhaps from one of the books Elixir in Action [3] or Programming Elixir. [4]
4. Finally, start implementing your cool personal project.
Ah, one more thing: Elixir School is also a wonderful resource with tons of information and examples [5] and of course the official Elixir website with its excellent docs. [6]
I guess is depends on what you're working on. There are a ton of things I've needed to understand about Erlang. gen_statem, gen_tcp, gen_udp, gen_event, crypto, ssl, etc.
Yes I agree, depending on the project you might need to dip into some Erlang libraries. But that's a far cry from needing to learn Erlang first.
I remember reading things like "you should learn Erlang before learning Elixir to be really effective" scared me off learning Elixir for a little bit as well.
Also, I find the more familiar you get with Elixir, the easier it becomes to read Erlang code.
I've happily dipped into Erlang libs when I need to. I'm also increasingly capable of reading Erlang code though I only write Elixir. I would not recommend starting with all of Erlang before doing Elixir but it may work better for some folks.
I'll briefly weigh in with others that you don't need to know Erlang, at least not Erlang syntax, to be effective in Elixir, and the semantics are identical. I think it's useful at some point to learn that all Elixir modules are just Erlang atoms, and to learn about OTP and that using anything built into Erlang is as simple as calling a function on an Atom instead of on an Elixir module. OTP is awesome, and so is Erlang, but I've been doing Elixir professionally for almost 3 years now and I've still never written a line of Erlang (though I did Prolog in college, on which its syntax is based, and I can generally manage to read most code in Erlang, but I've not found the need to often). Even Erlang libraries can be used from Elixir without any special interop, as long as they're published on hex.pm via rebar3. You just add them as a normal dependency in your mix.exs file, and it just works.
This makes me not want to learn elixir. Learning one language and becoming masterful at it is hard enough. There's too many "learn this language, but also this other language and platform"'s in my life (JVM-based work, and anything in the front-end JavaScript world it feels like these days). It just feels like you are telling people "Here, learn this language, but also learn the assembly instruction set for your architecture as well" -- that's not the reason I choose to use higher level language.
What does it mean for you “learning one language and becoming masterful”?
You can learn the syntax of Elixir, Python, Go, whatever very fast, but becoming a master is much less about its syntax - that is usually a trivial part. It is more about underlying standard library, concurrency, collection, execution model, GC, patterns, and caveats.
yeah probably it's not expressed very well. You don't need to learn the syntax of erlang to understand Elixir. You can call any erlang code from within Elixir in a format that almost completely looks like elixir (the difference is that Erlang modules have a colon and start with a lower case and Elixir modules are upper case).
You might need to learn to read erlang documentation. But I've done quite a bit in Elixir, from standing up websites to writing a VM orchestration engine, and the only things I've needed to read the erlang docs for were:
1) writing an Elixir library that wraps the builtin erlang :ssh module with a more elixirish syntax
2) writing an Elixir library that wraps the builtin erlang :gen_statem module with a more elixirish structure and syntax
3) writing an Elixir library that fixes and wraps the builting :tftp module with a more elixirish syntax
4) figuring out how erlang uses SSL so that I could write a two-way encrypted SSL rpc library.
I did them for fun, but all of these are either in prod or used to make production artifacts, and all of these are of course open source and available, so you can use them and not have to do what I did.
Also FWIW, I have read exactly zero of those books.
I think there's a distinction between understanding and learning a language. In this case, it helps to understand Erlang in order to learn Elixir. Just like you're eventually going to need to be able to read some C if you dive really deep into Ruby.
Difference is that C is probably considered basic knowledge for a working programmer, Erlang isn't. Professional programming eventually leads to being a polygot anyway.
You don't need to learn Erlang to learn Elixir. You can just use some what Erlang provides when you need it. Some people want to approach things very ground-up but I've taught people Elixir. It's fine to learn Elixir and you'll get to OTP and all the good stuff.
3. As you figure out which features you want, look up things on a need to know basis
And repeat that loop until your project is done.
As for learning material to help with step #3, assuming it's a web app, personally I found looking at the source code for https://github.com/thechangelog/changelog.com/ to be highly valuable. The Programming Phoenix 1.4 book is great too to fill in some gaps of a "self learner". Also Alchemist Camp is quite good for seeing how to do 1 specific thing or generally look for workflow / implementation ideas.
I like to get a "lay of the land" before I commit to a new lang so I read Dave Thomas' book on it while playing around with the language on small personal projects (same way I handled Ruby, read the Pickaxe book and did a few language experiments on my own). But YMMV.
I will say this- once you read the book it becomes ENTIRELY obvious to you who has not, when they ask certain questions, like "what is a sigil?"
After reading through the guides on the official website I went through the course on learnelixir.tv- basically the creator runs through each topic in the language in a series of videos in his code editor. I think it's $20 or so for permanent stream/download access and access to any new videos he puts out. (Maybe the creator is on HN?) I got most of my team up to speed on elixir this way.
I went through a bunch of exercism problems and felt like I learned a lot about the language syntax and control flow (which I think is pretty awesome).
However it doesn't teach you much about the concurrency model or Erlang/OTP, which I hear is the real reason for using it.
Lots of good suggestions here. You mentioned Ruby so I am going to assume some usage of Rails. There is a good presentation from ElixirConf 2019 about learning Elixir first before diving into Phoenix. Keep that in mind as you think of personal projects.
if you are a rubyist, I can't more strongly recommend watching this video, which has nothing to do directly with Elixir (in fact it precedes elixir by a couple of years) but if the topics that Bernhart (of wat fame) brings up resonate with you, then you will really like Elixir.
Also this blog post helped my understanding http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoe...
Phoenix LiveView [0] is really exciting to try out in Elixir. I'd recommend building an auto updating dashboard.
I had a micro controller that had various sensors on it that I connected to over a serial port using circuits_uart[1]. I then read the sensor values and displayed them on a LiveView dashboard. Totally pointless but super fun :)
[0]: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... [1]: https://github.com/elixir-circuits/circuits_uart
Sidenote. If anyone has any Elixir freelancing work I can do send me an email. Email in my HN bio.