"Use the right tool for the job"
The above statement is conventional wisdom that I'm sure most of us programmers would generally agree with, but let me ask you this, do you think each of the 20 most popular programming languages are different tools meant for different jobs?
For example, consider the following five programming languages: Java, Python, Ruby, JavaScript, and C#.
Are these five languages so unique that you'd call them different tools meant for different jobs or do they seem more alike than they are different?
There was a time when you could say "JavaScript is a language that runs in the browser", however that statement doesn't work anymore... Today JavaScript is a language that you can use almost everywhere: Browsers, Servers, Embedded Devices, Databases... So is JavaScript the right tool for every job? NO, of course not! but people keep trying
I think if you squint your eyes, the vast majority of popular programming languages look more similar than different. Sure, they all have different styles and idioms, that may or may not resonate with you, but I still think most popular languages, fundamentally aren't all that different.
Because most popular languages were designed to be general-purpose, sequential languages that can solve all sorts of problems. I mean, if you think about it, languages only become popular, when they have broad appeal, and can be used to solve many different problems... right?
But here's the thing, you can't write a programming language that's excellent at solving all possible problems, just like you'll never be able to make a meal that everyone likes.
This course teaches you the Elixir programming language, which you should know, isn't like any other popular languages.
Elixir is a modern concurrent functional programming language, that solves certain types of problems, in a unique, novel and a very effective way... In other words, Elixir is clearly a different tool, meant for certain types of jobs.
I'm going to explain what Elixir is really good at in a moment, but before I do, ponder the following statement:
Elixir is a language that allows you to write software that can effectively "run forever"...
Ok before you send me a nasty email, nothing runs forever... I know that, but programs written with Elixir can have ridiculous uptimes, far longer than any other languages except for Erlang, but I'll talk more about Erlang in a moment.
Well, it doesn't happen by accident... this is possible in Elixir because in part, that's what it was designed to do.
So when would you use Elixir? In other words, what kind of "problems" is it good at solving?
Well, Elixir is excellent for creating web applications and APIs that are highly responsive, massively concurrent, fault-tolerant and distributed.
Elixir is also really good at creating embedded software, but in this course, we'll focus on Elixir, in the context of web development.
Ok, you might be thinking, "I can create web applications and APIs in plenty of languages, so how's Elixir different?"
If I had to give just one answer to this question, my answer would be: "Elixir handles concurrency far better than any other popular language!"
I'll give you some examples:
A few years ago B/R (Bleacher Report), a sports news site, was experiencing significant growth (billions of monthly page views) and was running into scaling issues. B/R was originally created with ROR (Ruby on Rails), which offers a great developer experience and productivity, but it kind of sucks at scaling and concurrency.
Some companies have been able to scale ROR, by effective use of caching, but caching isn't something B/R could use, because each B/R user has a personalized news feed, which doesn't lend itself to caching.
Initially, B/R dealt with their growth challenges, by adding more and more servers, but eventually they decided to look at alternatives to ROR, that could help them address their scaling challenges, so they looked at a few different languages such as JavaScript/Node.js and Golang, but they eventually chose Elixir, and they started migrating from ROR to Elixir & Phoenix.
After migrating the resource-intensive services from ROR to Elixir, B/R was able to go from 150 ROR servers, down to just 5 Elixir servers, and they felt like they could have gone down to just 2 Elixir servers, but they were extra cautious and they preferred to over-provisioning a bit.
Going from 150 to just 5 servers is pretty impressive, but there's more to Elixir than just scaling, but I'll get to that in a moment.
Let's look at another Elixir success story in Discord which is a startup that provides a text chat and voice service for gamers.
Discord knew from the very beginning, that they'd need to build a highly concurrent system and they boldly chose Elixir from the start... I say boldly because they committed to Elixir very early, well before it was a proven technology.
After about 2 years of service, Discord was servicing 5 million concurrent users, then a couple years later, they were servicing 11 million concurrent users.
Now, Discord is at a scale most of us will never have to deal with, and as such, they've found several hot spots in their code that required creative solutions, but they've been able to make it work quite well, and here's the kicker, when they had 5 million concurrent users, they only had 4 infrastructure engineers.
Ok, you might be saying to yourself "I don't have scaling challenges like B/R and Discord, so why would I use Elixir"?
Well, even if you don't have scaling challenges today, it's nice to know you're creating software that can scale when needed, but even if you never need the massive concurrency that Elixir offers, you should still consider Elixir for a bunch of other reasons. I'll describe a few of the big ones:
-
Concurrency: because of how concurrency is handled with Elixir, there are features you get in Elixir that other languages can't offer. For example, implementing real-time features in Elixir and Phoenix is trivial, especially compared to other popular languages.
-
Responsiveness: Elixir is very responsive and offers consistent low-latency responses because of features like preemptive scheduling and how garbage collection is implemented... in other words, with Elixir you'll be able to offer more consistent, stable and reliable services.
-
Availability: it's relatively easy to create highly available services with Elixir because distributed computing/clustering is a native feature.
-
Fault-tolerance: because of how fault-tolerance works in Elixir, errors and bugs are isolated and typically have no impact on other parts of the system. In other words, it's virtually impossible to have bugs that take down your whole server, and with Elixir, you won't find yourself restarting servers to recover from bad errors or bugs.
By the way, if you wanted to write software that could "run forever", you'd need all the features I just described, right?
Elixir is a very capable language that offers many unique and interesting features, but it also offers an excellent developer experience, similar to what Ruby on Rails offers... Basically, with Elixir you can create excellent systems, with unique features, that scale well and are maintainable, and you'll find yourself very productive and you'll probably really enjoy using it.
"Ok, but Elixir is young, so I'm sure there are plenty of growing pains you'll need to endure, right?"
Well no, not exactly, let me explain.
Programs you write in Elixir, are compiled into bytecode that runs in a virtual machine. The virtual machine that Elixir uses wasn't created for Elixir, it was originally created over 3 decades ago for a language called Erlang.
The truth is, Elixir is nothing without the Erlang Virtual Machine, in fact Elixir wouldn't even exist, without Erlang.
Now, Erlang has most of the same features that Elixir has, which might make you wonder, why not just use Erlang?
Well, if you look at Erlang, it isn't the nicest language to read and use... In fairness, most languages that were created over 3 decades ago, can't really compete aesthetically with modern languages. Now, some people actually like Erlang, but I suspect most people who take a cursory look at Erlang are quickly turned off by it's syntax.
The reason I'm telling you about Erlang is because its virtual machine (which Elixir uses) is mature, battle-tested and rock-solid, so even though Elixir is a relatively new language, it's runtime is more mature and proven than pretty much every other runtime.
Recently, José Valim, the creator of Elixir, was asked:
José's answer was effectively Yes... well he didn't say yes, he preferred to call it stable... Basically, there are no big features or breaking changes on the roadmap, and there are no firm plans for a version 2.0... well, I bet there will be a version 2.0 at some point, but hopefully, you get the sentiment, about the maturity of the language.
I'm pretty sure we're past most of the growing pains with Elixir, and it's a great time to learn and start using Elixir, but don't take my word for it, look at what others are saying, like InfoQ and Gartner Research, who say it's ready for prime-time and they're suggesting that organizations start considering Elixir because it can provide a competitive advantage.
Yep, you can find hundreds of companies that use Elixir, in this list, but I suspect there are actually thousands of companies using Elixir, with more adopting it every day... You're probably familiar with some of the companies that use Elixir, such as Pinterest, Moz, Slack, Pepsi, PagerDuty, AdRoll, Bleacher Report, and Discord.
We'll start with the basics, and work our way through the major features in Elixir, then we'll start learning the Phoenix web framework.
There are more than 150 videos, totaling ~17.5 hours of video content that covers the following topics, and much more:
- Data Types
- Pattern matching
- Flow Control
- If/Then, Unless
- Cond
- Case
- Functions
- Anonymous and Named
- Higher Order Functions
- Pattern matching & Guards
- Pure vs Impure
- Pipe Operator
- Recursion
- Tail Call Optimization
- Collection Processing
- Map, Filter, Reduce, etc
- Composition with the pipe operator
- Streams
- Comprehensions
- Protocols
- Macros
- Build tools
- Testing
- Functional Programming Concepts
- Processes
- Long-Lived & Short-Lived
- Sending and Receiving Messages
- Error Handling
- Supervisors
- OTP
- GenServers
- Supervisors
- Applications
- Agents & Tasks
- Phoenix Web Framework
After you've learned the basics, you'll put what you've learned into practice by building an interesting final project.
Imagine that you and I are on a team that just landed a big contract to build an exit polling application.
"What is exit polling?"
Well, it's a way of estimating how people are voting on election day, and the estimates are determined by asking a sampling of voters who they voted for, immediately after they leave the polling booth.
This project is a bit scary, because, before election day almost nobody will be using our application, however, on election day, our app will experience a massive spike in usage... somewhere between 10,000 to 100,000 concurrent users.
Let me explain the expected usage pattern, in more detail.
Leading up to election day, there will be just a few users, setting up the master data... In other words, adding the voting districts, the questions to ask voters, and the valid choices for each question.
On election day, there will be a huge spike in usage. A small part of the usage spike will be from people conducting the exit polls, on their mobile phones.
However, the vast majority of concurrent users will be pollsters, political campaigns and news organizations that will be monitoring the exit polling results all-day long.
So basically, there will be 3 parts to our final project:
- An admin area for adding and maintaining master data.
- A polling section, which will be used to conduct exit polls.
- And lastly, there will be a reporting section, which displays the exit polling results and updates them in real-time, as new polls are conducted.
The admin part of the app will consist of several server-rendered crud pages.
The Polling and Reporting parts of the app will be a single page app, written in React.js. We won't create the React app in this course, as it's outside the scope of this course, but we will create several rest endpoints and a phoenix channel that will get used in the React.js app, then we'll integrate the React app with Phoenix.
Well, you're going to need to take the course to find out, but just so you know, the solution we'll create is very different from what you'd do in other popular languages.
This course is meant for students who are already familiar with HTML, CSS, and HTTP.
Ideally, you should have some experience with another programming language... In other words, I'm assuming you have at least a small amount of general programming knowledge. This isn't to say a total newbie can't succeed in this course, but I think it would be pretty challenging.
This course has 150+ videos, totaling ~17.5 hours, of thoughtfully created content covering Elixir version 1.9 and Phoenix version 1.4. You'll also have plenty of exercises and challenges throughout the course, to give you some practice and to keep you engaged.
You can watch the first few videos to see what we'll be covering, and to get a bit of an overview.
I offer a no questions asked, 30-day money-back guarantee. So, if for any reason, you'd like a refund, just shoot me an email within 30 days of your purchase, and I'll promptly provide a refund.