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.
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.
It is useful for implementing anything where there is a calling interface/surface with a bunch of verbs that can take parameters.
Which is pretty much everything in programming.
Which is why it's (also) useful in API dev.
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?
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 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 :-)
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?
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).
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.
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.
How would you recommend to learn Elixir? And a follow-up: some ideas for personal Elixir-based projects?
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.
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.
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.
https://elixir-lang.org/getting-started/mix-otp/introduction...
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.
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.
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]
–––
[1] https://www.amazon.com/Programming-Erlang-Concurrent-Pragmat...
[2] https://www.amazon.com/Erlang-OTP-Action-Martin-Logan/dp/193...
[3] https://www.amazon.com/Elixir-Action-Sa%C5%A1a-Juri-cacute/d...
[4] https://www.amazon.com/Programming-Elixir-1-6-Functional-Con...
Learn elixir use it, you can be very productive with it. If later for whatever reason you want to dive deeper into Erlang you can.
I’ve used elixir for 5 years now. And I’ve never had to Erlang, the most I’ve done is use some Erlang libraries in elixir.
Elixir can stand on its own
1. Figure out what you want to build
2. Read the getting started docs a bit
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.
After that, I would recommend taking a look at Elixir in Action from Saša Jurić
I find the videos to be great, both in terms of quality and pacing. Make sure to use the coupon code 'elixirforum' (without quotes) to get 10% off!
Its author—Dave Thomas—also wrote prag prog's Programming Elixir book, which I found very helpful a few years ago.
https://pragmaticstudio.com/courses/elixir
The Elixir course is $89.00, but you'll learn a ton about the language for that price. The course is worth every penny.
NOTE: I'm not affiliated in any way with Pragmatic Studio. They just make excellent courses.
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?"
However it doesn't teach you much about the concurrency model or Erlang/OTP, which I hear is the real reason for using it.
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. :)
Being on average 10x faster at the same kinds of tasks than Ruby is, also helps, of course >..<
All subsequent releases will focus on improvements and bug fixes. Not new features.
https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
>> ”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!”
Edit: fixed for clarity
> 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.
I really love the years of work you’ve put into Elixir (and Phoenix as a framework).
Can’t say thank you enough.
thank you!
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.
The learning process has been, frankly, incredibly easy. I read a bit of Saša Jurić'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.
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.
1: https://elixirforum.com/t/jose-valim-announces-his-new-elixi...
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?
But from my end it looks to be improving. I've gotten going with doing it professionally and I hope to maintain that focus mostly.
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.
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.
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.
Saša Jurić'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 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.
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 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.
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.
- 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.
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.
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.
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...
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.
Although finding green and red mismatches in pages of output of your data structure was fun :)
.. no
Thanks for the work on Elixir!
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:
def fact(0), do: 1
def fact(1), do: 1
def fact(n), do: n * fact(n - 1)
# remote function pointer
f = Foo.bar/1
# closure
f = fn x -> Foo.bar(x) end
# closure with anonymous parameters
f = &Foo.bar(&1)
Oh, and this also exists:
f = &bar/1
Oh, and one more variant:
f = some_mod.foo/2
https://elixir-lang.org/getting-started/basic-types.html#ide...