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.
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.
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 :)
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.
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 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]
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.
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.
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.
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.
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.
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'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.
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.
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?"
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.
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.
It is curious to see Plataformatec being referred to as Elixir's parent company but I guess it makes sense legally. Plataformatec does own the trademarks for the name and language - which we are currently working on moving the control to the Elixir Core Team.
In terms of development, however, it is more of a shared custody by many community members and companies. For example, Elixir Core Team has 6 developers and only one of them was employed by Plataformatec (me).
So I would describe Plataformatec as an incubator. Elixir wouldn't exist without their support but even back in 2013/2014 we already had other companies investing in the language and the ecosystem. An investment which has grown over the last years. Plus, I am still directly involved in the same capacity as always, as this release shows. :)
Thanks for your work Jose! My second dev language in my career after PHP was Elixir, and I think I’m a better developer for it. It took me months to learn, I felt like I was learning Martian, but I hope to get back to a job where I’m working in Elixir some day.
Gotta say "thank you" for finding the guts to pursue a new language, I think it's been my favorite of them all so far, and the code I've written in Elixir has always been very resilient, very easy to read, very easy to debug and very maintainable (not to mention, just fun to write!)... something which I credit more to Elixir's (and BEAM's) design more than my own.
Being on average 10x faster at the same kinds of tasks than Ruby is, also helps, of course >..<
>> ”As mentioned earlier, releases was the last planned feature for Elixir [v1.9]. We don’t have any major user-facing feature in the works nor planned. I know for certain some will consider this fact the most excing part of this announcement!”
I think the keyword in the v1.9 announcement was "major user-facing features". :) Back then we also said:
> We will continue shipping new releases every 6 months with enhancements, bug fixes and improvements.
I would say v1.10 is quite close to this sentiment: a bunch of improvements and enhancements but nothing really major. The main new feature in v1.10 is "compiler tracing" but that will be directly used by a small subset of the community, to improve the tooling, instead of being something everyone would use from the get go.
Hello Jose, first of all, thank you for Elixer and Phoenix. A question that has been bugging me for a long time why Phoenix (arguably, built on one of the most reliable and battle tested stacks) has a dependency on NPM, something that I'd rather not see on any of my computers at all. Would you care to give insight into how this decision was reached and what if anything can be done to do Phoenix development and deploys without any NPM dependencies?
I believe there is a flag you can pass when you create your Phoenix application that removes webpack/npm/etc. If you are using Phoenix to build APIs, then you can pass `--no-html`, that will get rid of these and other dependencies. However, if you are writing JavaScript/CSS, than it is most likely that you want to use the tooling that exists in the Node ecosystem.
Asking for "the advantage" is probably not quite the right question. Different toolbox, different tools, for different solutions to different jobs. Elixir runs on the Erlang VM, is functional, has a Ruby-like syntax.
How easy (or hard) is it to learn Elixir for someone with Python/PHP/JS background and zero knowledge of functional programming? Also, are there job opportunities for Elixir or is it a niche language?
As far as functional programming languages go, I think Elixir is probably one of the best intros: especially for someone coming from another dynamically typed language like Python or PHP. The syntax will be far less foreign than a language like Lisp or Haskell. You won't have to deal with types (though they are neat to learn, too).
Elixir is not quite as popular as Go. But there are absolutely job opportunities out there. And huge projects currently using it (e.g., Discord). I wouldn't focus on needing there to be a job market to learn something new, though. You'll learn techniques and a new way of problem solving that will make you a better Python, JS, and PHP programmer, even if you never professionally work as an Elixir developer.
I don't really agree that Elixir is a good intro to functional languages. It doesn't really teach you much about the functional paradigm as Elixir is fairly imperative by nature.
It focuses on practicality rather than adhering to the functional paradigm (lambda calculus etc.). That's probably the right choice for building highly concurrent industrial systems, but purely for learning about FP not quite as good as something like Elm would be.
Here I thought that's exactly the fact that makes it less ideal for learning about the functional paradigm.
You also spend a considerable amount of time on Elixir learning how to architect fault tolerant concurrent systems. While useful, this doesn't have much to do with functional paradigm per se.
I find it approachable for someone that doesn't know FP. It doesn't require shifting all of your knowledge and habits at once. It might not teach you everything there is to know about FP but I think the question originally was roighly "is it hard to learn if you don't know FP?"
And I'd say for that type of case it may be more approachable for not being qiite so pure.
Approachable it certainly is, I'm not disputing that at all. The less functionally aligned a language is the more approachable it is to developers with little to no exposure to FP.
Personally, learning Elixir didn't really help me understand many fundamental FP concepts such as function composition & higher order functions, algebraic data types, referential transparency, functional purity, currying etc. It was only after spending time learning Elm and Haskell that many of these things dawned to me.
So I'd say if your aim is to really learn about the functional programming as a paradigm, there are better alternatives out there.
Easy enough, for me. I have roughly the same history of languages. Functional programming as a paradigm was the biggest hurdle for me. But Elixir guide docs help yout quite a bit there.
Job opportunities are fine, not Python+ML or JS+React great but there is work out there.
This isn't to say there aren't disadvantages, too. But for advantages, specifically, I think some pros of Elixir are:
- It runs on the Erlang VM, which is (tech-wise, anyway) fairly old and battle tested. It was deliberately built for resiliency and concurrency. It has some very clever concepts, like supervision trees, cheap processes, interprocess communication via message passing (hey, sounds like OO, right?), and 0 downtime deployments built-in.
- Its creators (namely Jose Valim) come from the Ruby community, and value a lot of the same things Rubyists do: good documentation, testing, and excellent tools for package management, debugging, builds, testing, etc. Several libraries are very similar to their Ruby counterparts. E.g., Phoenix will feel very familiar to a Rails developer. Ditto, the syntax is kind of similar to Ruby. The paradigm is completely different, as Elixir is an immutable, functional programming language. But... aesthetically, they look similar-ish.
> and value a lot of the same things Rubyists do: good documentation
In my opinion, the Elixir community (at least for the core language and major libraries) does documentation better than any other environment I've used. Almost every question I've ever had about using Elixir, Phoenix, or any of a dozen other libraries has been answered by using hexdocs.pm. The few things that aren't clear from those docs can generally be resolved by reading the source.
After that, elixirforum.com or the elixir slack give me higher level discussions on less immediate issues. I don't recall ever needing Stack Overflow for any elixir question.
Speaking of excellent documentation, from the documentation you can jump right into the code and see how a particular elixir function is implemented. Super useful personally for me as a learner. For example , go to https://hexdocs.pm/elixir/Enum.html#map/2 and click on the little "<\>" on the top-right
Elixir (really, the Erlang VM it's built on) is designed for highly concurrent, reliable systems. For my org, building a distributed webapp, we chose it over the languages you listed because of how much you get "out of the box" with Elixir.
Saša Juric's talk "The Soul of Erlang and Elixir" (https://www.youtube.com/watch?v=JvBT4XBdoUE) is a good introduction to why someone might choose Elixir. The payoff is the slide (https://imgur.com/gallery/G6lfUW6) where he compares the stack of a "traditional" web app (Nginx + Ruby on Rails + Go + Redis + Mongo + Cron + Upstart) to the Erlang rewrite of the same app, which is... just Erlang.
This isn't to say that Erlang ships a complete replacement for Redis, Mongo, Upstart, etc.—but it provides most of the functionality that most apps will need, such that your dependency tree can be much simpler. It's really nice to not have to become an expert in all the infrastructure surrounding a normal web app and instead just learn Erlang/Elixir.
> It's really nice to not have to become an expert in all the infrastructure surrounding a normal web app and instead just learn Erlang/Elixir.
It is also so much easier to test when all of your architecture is in one form. You don't have to spin up whole deployments on real infrastructure to see if the parts still talk - your normal local unit testing architecture gets you much more confidence.
I hadn't seen that slide, it's pretty compelling. Is there a story for typechecking or a typed language that runs on BEAM? This is one aspect that holds me back a little.
Erlang's type checker Dialyzer has an Elixir wrapper called Dialyxir (https://github.com/jeremyjh/dialyxir). As someone coming from C++, Dialyzer leaves a lot to be desired—I still miss C++ type checking—but it's better than nothing.
The Norm library (https://github.com/keathley/norm) is an attempt at higher-level, more expressive type checking which I think shows a lot of promise, but I've not adopted it in a real project yet.
The language itself is a dynamic, functional programming language. The benefits of functional programming languages have been much discussed (and much disagreed with), but Elixir is a particularly gentle introduction to the space while being a great language to work with.
The other key feature is that Erlang/Elixir/Beam implement 'the actor programming model'. This is a series of separate bits of code that have their own state and communicate to each other with messages. It turns out that for long running processes (web servers, control software etc.) this model is an excellent way to build your code. A lot of code ends up doing a subset of this, and usually not that well. Elixir gives you the tools to do it properly and easily.
Rust: much lower-level systems language which will take quite a bit more development time.
Go: Go's CMT implementation is fundamentally broken (you can't just use go channels without mutexes for complex work unless you want your application to have bugs). Elixir and Erlang Actors have much better guarantees.
Java: BEAM is slower than the JVM, but much more stable. Native actors are a much better experience than Akka.
Python: Django finally added initial support for async development, but library support is a long ways off (and the GIL is its own issue). BEAM is about an order of magnitude faster than Cpython (though probably similar performance with pypy). If you prefer Ruby syntax over Python, there is no contest here.
My big question is less Why BEAM? and more Why Elixir?
I prefer the native Erlang Syntax, LFE/Joxa (lisps), or alpaca (ML family with static types) over Ruby-ish syntax.
I came from Python. For me Elixir was much more approachable as a first step into a functional language. Syntax, documentation, getting started/onboarding. I believe there are efforts under way to make Erlang docs a bit easier to approach.
And then Phoenix with projects like Presence really built my excitement for the language. Had some colleague that was thrilled by Ecto changesets.
So a combination of ergonomics, easily accessible to new people and strong hype-marketing brought me in I guess. And I enjoyed it and am happy with the results it gives.
I'd not written any Ruby before touching Elixir (and still don't, barring tools like Dependabot and Vagrant), but far and away prefer Elixir's syntax to Erlang.
I write scraps of Erlang from time to time, but hate the idiosyncrasies such as the rules behind commas and full stops, and variable names starting with capitals. There are so many other weird quirks too, like how strings are handled.
A very interesting language on powerful platform with a promising web framework. Many saw it, myself included, as a Ruby / Rails Improved, and expected its quick growth.
Unfortunately, initial enthusiasm a few years ago did lead to its wide adoption.
I talked with a couple of companies that jumped on it initially, but later decided to move to Java, Kotlin, Go. The main reason was difficulty to hire engineers to scale up quickly (in Europe), not some technical disappointments.
Sadly, it seems that being a scalable platform is not enough to scale up to business needs.
I recently had a convo with a company that moved into Elixir because they had an easier time hiring as they could tap into the local Ruby developers and into folks interested in functional programming (in France). Would you mind saying which country in Europe in particular? Was it also France?
Weird, on the Elixir forums and slack channels there seems to be a fair number of developers working or wanting to work in Elixir. Perhaps the initial uptake in interest outpaced the developer interests in some areas. It'd be interesting to know what the community is like in Europe.
Based on the recent formation of Dashbit [1] and larger companies like PepsiCo (?!) among others openly jumping onboard I think means Elixir has reached a clear point of sustainability for those willing to find (and train!) devs. Likely it'll never be RoR level, but I'm fine with that if it keeps the dev community more selective. Functional programming in general seems to be a bit of a self-selector.
I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...
I see comments like
This:
>A very interesting language on powerful platform with a promising web framework... I talked with a couple of companies that jumped on it initially, but later decided to move...
And this:
>I recently had a convo with a company that moved into Elixir because they had an easier time hiring...
I see this comment pair somewhat often.
Also,
From @hajile
>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here.
>BEAM is slower than the JVM, but much more stable.
The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).
This makes a lot more sense to me:
>Functional programming in general seems to be a bit of a self-selector.
I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."
But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?
Honestly I think you are doing things backward. With all due respect to the fantastic platform and vm that the erlang folks built, it's just not as joyful as elixir. And I feel like writing legible and organized code is easier in elixir since it's opinionated, about everything from directory structure to documentation to tests, and a couple of detailey things like structs are easier to read than records and macros are more sensible than string preprocessing
Definitely agree, though I respect the effort/desire to learn Erlang first given the fact the first time I saw Erlang code I was so confused/put off by it, the syntax was so foreign (not c-like, not lispy), variable names up capitalized, atoms are bare words, source files are just tons of functions, the tooling isn’t anything like modern languages (though since Elixir and hex/mix, that situation has gotten way better), then you’ve got all the OTP behaviors which are entirely unique to Erlang/BEAM, Erlang’s documentation though excellent and extensive isn’t by any means beginner friendly (IMO), and to top it all off, unless you’re coming from another pure functional language you have to deal with working in a new paradigm. Basically, Erlang is intimidating, which is unfortunate because how powerful BEAM and the OTP behaviors are.
However, Elixir wraps up the power of the BEAM and OTP in a much more approachable package. The syntax is much more familiar (thanks Ruby), provides tooling on par with (and better than some) popular modern languages, the language itself also provides more modern user friendly features (macros, pipe operator, protocols, etc). All with a community that is very beginner friendly and willing to help.
If you want to make use of OTP/BEAM, Elixir is by far the best way to enter. When you learn Elixir, you will also learn the major OTP behaviors and concepts (Supervisors, GenServers, Applications, Registry). Eventually you’ll find that there are even more goodies in the beam not directly exposed by Elixir (genstatem, ets/dts/menisia,timer,digraph — are a few of my favorites). Fortunately though, you can call Erlang modules/code directly from Elixir (and vice-versa), so you’ll then eventually dip your way into playing with Erlang modules as needed and when you approach the docs after having experience with OTP with Elixir, you’ll notice a lot of things are familiar and the Erlang docs become much less intimidating.
Basically Elixir is a much easier entry point to Erlang. Erlang is a great language, but very different with a lot of new concepts and which can kill your motivation to learn how awesome the BEAM is, so if you want to learn Erlang, by all means give it ago, but if you find yourself frustrated/confused with it, try Elixir for a while, then come back to Erlang and I bet it will be a lot easier.
When I initially saw Erlang, I was put off, the docs were confusing and I would avoid them at all costs, always try to look for an Elixir wrapper. Now after having worked with Elixir a lot? I frequently find myself going to the Erlang docs first to find a solution instead rather than hex or whatever. I can easily grok my way through an Erlang projects source, which previously was completely foreign to me. Will I ever likely write anything serious in pure Erlang? Probably not. Am I saying if you learn Elixir you will also just pick up Erlang? Absolutely not. What it will do though is make the process of learning Erlang (if that’s the goal), and it’s absolutely massive built in library of tools/abstractions/patterns that no language I’ve seen comes close to replicating an order of magnitude easier.
You may like this: the very odd gen_statem callback pattern exists to group different callbacks by state (which you can't do because you need to group like headers together). But in Elixir, we use modules and macros to organize our code more sanely and less ad-hoc-ey:
I've only had 2 complaints with gen_statem, the docs were initially some of the most confusing/unclear and the state_functions callback mode (which I think partially is to blame for my first complaint as I was expecting a more gen_server like api with handle_* functions -- which exists but the docs use the state_functions for most of the examples and the handle_event just kinda getting some "oh by the way this exists" examples). I actually initially decided to just keep using gen_server's with a "status" or whatever value in their state as I figured it was good enough. At some point over the next few weeks I actually ended up having this talk[1] pop up in the recommend videos, and I figured I give it a watch to see if it would help make sense of gen_statem or at least just confirm that I don't need it. And while watching it, once he started explaining actions (timeouts, state_timeouts, postponing, etc) I realized that gen_statem literally solves so many problems that I've had in the back of my mind on the project I was working on like "I should figure out a way to change the state of A and do something when it doesn't receive any messages from X,Y,Z processes" (gen_statem's timeouts!) or "how should I handle messages received while attempting to recover, I guess I could put them in a queue or something..." (oh, gen_statem will let me postpone them until it's healthy!). It took a couple more re-readthroughs of the docs to fully grasp, but now it gets included in almost everything I work on, it's so useful (though I guess I should've assumed those were already solved problems by the BEAM/OTP as usual).
However, now my biggest complaint about Elixir is that gen_statem didn't get any official wrapper. StateServer looks like almost exactly what I would want out of an official Elixir wrapper. I also like to see the addition of `handle_continue` as well, because the first thing I did before migrating any of the gen_server's to gen_statem's was create a small wrapper module to a) make the handle_* return values more in like with GenServer's (basically just making it {:(no)reply, (transition|keep), data, [actions]}) and b) add a quick and dirty handle_continue callback because I use it all the time with GenServer. And this literally just looks like a more polished version of that, so thanks!
> I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...
Watching videos of Joe talk super impressed me. He kept the same enthusiasm for programming as any college age programmer. That's impressive!
> From @hajile
>>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here.
>>BEAM is slower than the JVM, but much more stable.
> The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).
There was a recent web-server benchmark that illustrates the performance and stability trade-off pretty well [1] (or older web-socket one [2]). The StressGrid benchmark shows Erlang/Cowboy achieving about roughly 1/2-1/3 the speed of the compiled options (Java & Go), and roughly double that of NodeJS. Erlang/Cowboy maintained very stable latency numbers after hitting it's peak however (see graph in [3]). There's an oddity with Cowboy 2, that appears to be due to HTTP/2 support but can be disabled (though HTTP/2 in theory should support faster client responses with less multiplexing of HTTP requests).
In general I'd say BEAM is on average faster than CPython, though recent CPython 3.x versions have improved a lot. Importantly BEAM is one of the few dynamic language/VM's that supports multi-core natively (Clojure & Julia for other two main ones?).
> I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."
True! It seems like either you love FP or hate it. It is a bit painful if you have a bunch of mutations you need to do on a complex object, but there's usually a way to refactor it so you avoid so many mutations. But often you have to think a bit first and be more explicit. On the other hand I modified a short Python script a few weeks back and it took me an hour to find a bug with some variable scoping/shadowing corrupting my data.
> But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?
There certainly are gotchas, with Erlang Distribution in general or with default tools like Mnesia (split brain, 2G file limit). One gotcha I saw from a great Youtube talk (that I can't find) was when using the standard Erlang distribution to distribute jpeg images. Erlang distribution network normally only opens one connection between each node, which when you try to send lots of large binaries will get saturated. Then things like PG2, and health checks, etc which require low latency will start breaking. That team solved their issue by creating a separate connection plane for image data, a few hundred lines of code. Similar issues can (apparently) can happen with BEAM software like RabbitMQ as well since it uses Erlang distribution internally. There's plenty of stories from people recovering from errors [like 4]. Erlang Solution's has a great collection of videos and blogs on Erlang & Elixir.
I'd agree with sibling comments, learning Elixir first is just much nicer for many devs used to Ruby or Algol family syntax. Capitalized variable names confuse me to no end in Erlang code.
I've been writing Elixir professionally for about a month now. I previously had zero experience with Elixir, Erlang, Ruby, or even any functional languages (though I have read quite a bit about functional programming, and adopted a lot of functional techniques in my C++ & Python).
The learning process has been, frankly, incredibly easy. I read a bit of Saša Juric's "Elixir in Action" and Dave Thomas's "Programming Elixir," but mostly I just dove in with the Elixir docs' tutorial (https://elixir-lang.org/getting-started/mix-otp/introduction...). I'm not claiming to be writing the best Elixir ever, but I shipped my first production app in the first week and it's been rock solid.
I think most companies massively overvalue hiring people with "x years' experience" in whatever tech they're using. Better to hire smart people with a solid foundation in writing good code and train them on your particular tech stack.
There are not a lot of people proficient (or even having some experience) in functional programming, and there are not a lot of companies using functional programming neither (1/100? 1/1000?). The chicken and egg problem.
Outside of map/reduce, which honestly even juniors out of bootcamps learn these days, I don't understand the claim that functional programming is hard. It's easier, and usually safer, because you have to keep less things in your head while you're coding.
Was it difficult to hire engineers proficient in Elixir, or was it difficult to hire engineers who could _learn_ Elixir?
When my employer decided to use Elixir for a new product, we had maybe 2-3 people experienced in Erlang/Elixir; for the rest of us, it was "'Programming Elixir' is on the bookshelf; start working through that." That and pairing with the more experienced devs got most of us up to speed enough that we were fairly productive in a couple weeks. Since we were basically a Rails shop at that point, the similarity to Ruby didn't hurt, and as I've mentioned elsewhere in this discussion, the docs for Elixir and major libraries are really good.
I started a new job a month ago that is all Elixir, with no prior Elixir experience, and honestly it's been completely fine. My only advantage was that I had used a functional language (Elm) for a while before it, so I was used to a functional approach.
I learned Elm and Elixir few years ago. In both case, it took me about a week from "hello, world" to having the feeling that I can program in that language. I did this using only online learning materials and the support forums for those languages. With a colleague available I imagine that things would have been even smoother.
A lot of companies vastly overestimate the difficulty of getting a decent developer up to speed with a new language. In a lot of cases, it might be easier to learn a new language than a new, complex library for a language that you already know.
anyone mind explaining the /# to me? like `Application.get_env/3`. been wanting to learn Elixir for awhile now, but didn't even know what do Google for that one.
not sure how i made it through my entire CS degree without learning this term. either that or i just don't remember it. anyways, thank you! this is really useful even outside of Elixir.
It's much more common than just Elixir programmers. It's a common concept in computer science, particularly in functional programming or languages which permit function overloading on arguments.
Edit to add: I've heard and used arity for at least 10 years, in particular in the Clojure community. I've heard of Elixir and understand it shares some common ideas with Clojure and Ruby, but never been a part of its community.
In functional programming classes at the uni you probably wouldn't hear this because if they teach Haskell which I assume most do, every function always takes just one argument. That's because functions are curried by default.
I personally haven't really heard this mentioned anywhere outside of the Erlang/Elixir sphere.
This thread really surprised me - I learned about arity when learning about ternary operators, which are pretty universal - you can find ?: in all sorts of languages. I think I was learning about C when I first got a detailed explanation on the subject.
Even if every function is curried by default (and "currying" is yet another concept that may be alien to users of some languages), it is probably still useful to know with what number of arguments a function can evaluate to a value that is not just another function
I think it's a useful name for a useful concept, not sure why they'd take it out, "Function.prototype.length" is a much poorer replacement semantically (but hey, Javascript isn't known for its correctness or well-thought-out design...)
I had never heard of "arity" either until I started reading about functional programming concepts. It seems to be used a lot within the functional programming world, but not so much outside of that.
It’s the literal identifier for a function pointer. Module.function/arity. (“Arity” = “number of arguments.”)
If you’re wondering “why add the arity”: Functions in BEAM are polymorphic on their arity, but not their argument types; i.e. multiple functions can share the same name but have different arity, but all definitions in a module of a function with the same name and arity are actually the same function.
When you see Erlang/Elixir code with multiple definitions of a function of the same name and arity, those are called “clause heads”, and are defining the function “by parts”; code like the following gets compiled into one function that branches internally depending on the arguments passed:
That out of the way: `Foo.bar/N` in Elixir code is a function-pointer literal, which you can pass around just like you're passing around a closure. These three lines are all equivalent in semantics:
# remote function pointer
f = Foo.bar/1
# closure
f = fn x -> Foo.bar(x) end
# closure with anonymous parameters
f = &Foo.bar(&1)
...in terms of what happens when you use `f` in your code; but the function-pointer version has lower overhead to call, and costs less memory to keep around, because it's not capturing anything from the environment. It's literally just a pointer.
Oh, and this also exists:
f = &bar/1
...which is a function-pointer referencing a local function in the current module. This distinction is important, because you can get local function pointers that point to private functions; whereas you can't get remote function pointers (the fully-qualified kind that include a module name) to private functions. It's kinda like C++ with private fields—you have to not use `this.` when accessing them.
Oh, and one more variant:
f = some_mod.foo/2
This isn't a function-pointer literal, but rather a function-pointer expression. `some_mod` here is a variable; this expression will give you a function-pointer to the function `foo/2` on whatever module is named by the atom in the `some_mod` variable. (This can only be resolved at runtime; your code will throw an error here when it executes this expression, if it finds out that `some_mod` doesn’t contain an atom, or that atom has no corresponding module, or that module doesn’t have a foo/2 function on it. You can catch this error, though; and the runtime itself catches this error to implement just-in-time module loading.)
Elixir as a language provides a very robust standard lib with most tools to accomplish many tasks that would require external dependencies in other languages. Combine that with the actor model, Erlang's vm and own std lib and you have a very powerful language for a wide array of problems.
I’ve been using elixir for about a year now. It really makes writing API code joyful.
The pattern matching concept works so well for handling the variation that happens in API request handling.
I also love working with Plugs. The pipeline nature of elixir translates directly into how you manage a request/response, and the plug abstraction pattern allows you to be explicit about what should happen, and hide the details in a clean way.
Overall, there are a few simple language patterns that, when used together, provide a lot of power and flexibility — without the drawback of over complicated code.
Reading the update to Enum.sort, I could see in my head how easy a change this would be in elixer.
Supporting a different second parameter (a symbol rather than a function) can be implemented with another function that pattern matches to :asc or :desc. They can each call the original function(s) too.
In many other languages you'd start `sort` with a conditional and that function would need to handle every case. Not here. Each function worries about itself and what it can handle.
There's a beauty and practicality that Elixir hits so well.
Highly doubt that would get me anywhere but. I'm searching for elixir/js apprenticeship. It could be non-paid and re-evaluated at later point. I have been tinkering with programming as a hobby for a while. Currently located at UTC+2.
I've been tempted a few times to dip my toes into Elixir -- I like the language and the BEAM concepts, but in my environment I always bump into the following concern..
Ecto v3 has been out for more than a year now, and there are still only two supported adapters.. MySQL and Postgres. In my environment, I use a lot of MSSQL and SQLite in addition to Postgres, and those adapters haven't been successfully ported over to Ecto v3 yet.. in looking at some of the threads related to porting efforts, it appears that it must be a fairly daunting process.
I always get to that point in my technical evaluation and wonder whether I ought to sit back and wait for a while yet, until the database stuff catches up and solidifies. I realize Phoenix can still use Ecto v2, but that just seems like it would add legacy dependency issues.. In actual practice, is most everyone using Elixir and Phoenix just sticking with Postgres/MySQL? Is there some other mitigating method that folks are using that makes Ecto support a non-issue?
I've been working with Elixir (and often Phoenix) since nearly its beginning, and I recently took a project that involved some interop with MSSQL. It has been tenable, but not a great experience. I'm not even using Ecto, just https://hexdocs.pm/mssqlex/Mssqlex.html. It works but is a little buggy, not much community support, and none of the nice things that Ecto gives you.
In one different project, there was a desire to deploy a Phoenix API natively to Windows clients. After poking and spending a few days looking at years-old Stack Overflow posts with no activity, we ended up pushing back on the requirement and going with a containerized solution.
Elixir/Erlang/BEAM is a wonderful stack and I probably use it for 50%+ of my software, but I would not choose it in an environment where interop with MS technology was a requirement.
I guess it depends on your needs and motivation... we recently completed the transition from Ecto2 to Ecto3, and while not totally trivial in our case, I think you could do in a way that wasn't hard if you maintained compatibility with both from the start, so that only config had to change. But also, what are your requirements for using SQLite and/or MSSQL? Are you looking at porting existing projects, or new services talking to existing production databases? It used to be common in Rails to use SQLite in development and in production use Postgres or MySQL, but I think everyone kind of acknowledges its better now to run the same database in local and production if possible, and it's so easy that motivation is gone. I once had to use MSSQL in production for a HIPPA compliance issue, so I understand that might be hard to avoid in some situations, and SQLite is certainly well suited to some embedded applications, but you could certainly try and work on porting the ecto 2 SQLite and/or MSSQL adapter from ecto2 to ecto3 as a project and I'm sure the community would be very supportive in helping if you have motivation. I might be interested in helping with SQLite, but I don't have any specific motivation so I'm not likely to start it on my own.
In my case, MSSQL hosts our main business databases which are directly tied to revenue.. If it were being built today, it would probably be on Postgres -- but migrating it any time soon would be prohibitive, and just not profitable.. MSSQL is expensive, but is a darned good database, so there isn't much push to move.
As for SQLite, we use it internally a fair bit for ETL processes, and as a starting point for most of our applications. 90% of the business apps that we end up creating never need anything more than SQLite -- the 10% that do either end up on MSSQL (if they have to tie in to our main databases) or on Postgres (for everything else).
Sounds fair on both counts... Good news from José above that the official MSSQL support is coming soon and will be merged into ecto_sql package.... and like I said, if you (or someone else) decides they want to work on updating the old ecto2 SQLite adapter to work with Ecto3, I can't promise much, but I'd be glad to try and help!
Also, as a note, my first production Elixir service didn't talk to a relational DB at all, and was basically a thin API wrapper around ElasticSearch... others I know have basically used it just for realtime features connecting to browsers with WebSockets for push via Phoenix Channels (or now LiveView)... so even without any of those database adapters you may well find a use case it's a perfect fit for, and where lack of those adapters is not an impediment! Either way, good luck!
SQLite is really handy for smaller use cases and being able to spin up a new project quickly and without dependenices. TBH I'm kind of surprised its missing from the list
My personal experience with MSSQL drivers (ORMs and lower level) for many younger, non-Microsoft endorsed, languages is that whilst they will work you will get caught with sharp edges. Until several years down the line and enough people who have the will/time and consolidate their efforts. That said, even MS official endorsed libraries can suddenly disappear (I'm looking at you msnodesql).
Having been down this path, without the time to dedicate fixing/working on a driver, I wouldn't even consider a non-"blessed" language in combination with MSSQL anymore. It was too much pain.
I think this hits on one of my biggest complaints with the Elixir and Erlang ecosystem. As a high level toolkit for building distributed systems it's great, but if you need to do something more low level you are often left on your own using a third party library. This on it's own isn't a big deal, Ruby has the same limitations. Unfortunately the Erlang and Elixir ecosystems aren't as big as Ruby, so that often means the third party libraries aren't so battle tested and features are limited. Often then are written for one company's use case, and don't do anything outside of that.
I run a SaaS product where the backend is Elixir (it's been going for 10 years, so originally written in pure Erlang) and part of it needs to do a lot of http requests. It's a bit of a unusual use case, as I need to do 1000s of requests per minute to different servers. It's not feasible to keep that many connections open, so the connection needs to be recreated each time. Using hackney (the #1 Erlang http client wrapper) I found that some requests often took much longer on average than other requests. I narrowed it down to being a problem somewhere on the client side, but Erlang doesn't provide any tooling for digging deeper into the lifecycle of a HTTP request. I figured maybe it's a problem with TLS and then found Erlang (I think its been improved in v22) had very poor performance when verifying SSL certificates, so I had to disable that. I switched to mint which is a wrapper written in pure Elixir which helped a lot, but still it a left a lot to be desired.
I wrote up a quick test in Go and found doing the same requests, it didn't have any performance issues or timing oddities, and the code was much simpler. I've hbeen working on extracting that part of the system into a Go app, called via gRPC. Unfortunately there is no official gRPC library for Erlang, and the only third party one has limited features that I've had to work around. So it's a bit painful, but don't get me wrong I love using Elixir and Erlang :-)
> I've hbeen working on extracting that part of the system into a Go app, called via gRPC
What if you called it via Port instead of gRPC?
We are also using Elixir at our SaaS for more than 2 years in production. There are times (although rare) when Elixir performance is just not enough. For those cases we tend to use Rustler, which makes integration with Rust code pretty safe and straightforward. Did you consider Rust instead of Go?
The TDS adapter for MSSQL is almost ready for Ecto v3 thanks to efforts from Milan Jaric. We are also planning to merge it into Ecto SQL, so it doesn't fall behind again.
Meanwhile, I have worked with a company that had to use MSSQL and they ended-up using two Ecto MSSQL adapters at the same time so they could cover all use cases, which is obviously far from ideal.
It is one of these things that, if we had updated it as we went along, it wouldn't have been so much work, but because it fell behind, the amount of work becomes quite big.
However, there are no plans for a built-in sqlite3 adapter, so your observation still holds true. Sometimes you will stumble upon a part of the ecosystem that is not quite there, and then you need to make a decision between waiting, developing it, or using something else.
I haven't looked into Elixir so it might not be at all similar, but you might look into F# + Saturn. I know Saturn is heavily influenced by Phoenix. There are a few different data access libraries that might fit your needs: Entity Framework, Dapper, F# Sql Provider, Rezoom.Sql.
My team and me rely heavily upon Elixir and the Beam VM within our startup and couldn't be happier. I'm glad to see continuous improvements beyond the acquisition of Plataformatec.
I'm curious to know more about the total cost of ownership of Elixir.
What's it like finding other developers with experience?
How long does it take to train people up?
How easy to understand the code base is it for developers who are 2 generations down from those that wrote it?
How good is the tooling/support/interoperability? When I'm using X service, do they already have an SDK are do I have to build it from scratch every single time because I'm using Elixir and not say Java or .NET.
What's the general level I have to hire at? Can the "average" developer (who's not that great let's be honest) learn it and be productive or do I need to hire very good developers for every seat (read more expensive)
I feel like language features and syntax is close to the bottom of things to consider...
Speaking as a sometimes Erlang developer: the ecosystem certainly isn't as universal as language $FOTM. That said, Erlang's concurrency primitives and runtime are second to none, and there is little that is more battle-tested in the industry.
Individually developers will be more expensive, but if you have a product that demands maximum leverage of concurrency (i.e. data-heavy api, whatever-in-the-middle services, multiparty real-time data), you will more than makeup the developer premium when you get to that point.
I havent hit Elixir yet, but it seems to make access to the Erlang runtime much easier. As far as SDKs/api, Erlang itself has primitives and libraries to build useful access to most APIs you can find. If you're worrying about what services you can access though, you probably don't need Erlang's features, at least not yet.
The new sort api seems like a significant improvement.
reply