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.
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?
The TDS adapter for MSSQL is almost ready for Ecto v3 thanks to efforts from Milan Jarić. 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 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 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.
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.
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 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.
Phoenix LiveView [0] is really exciting to try out in Elixir. I'd recommend building an auto updating dashboard.
I had a micro controller that had various sensors on it that I connected to over a serial port using circuits_uart[1]. I then read the sensor values and displayed them on a LiveView dashboard. Totally pointless but super fun :)
For a fun and complicated Elixir project, you could try building a process pipeline that uses all your CPU cores to crunch some data. Look into Elixir Flow [0], for example, which has a fun guide on counting words in a file.
Elixir & Phoenix work well for web projects. The Phoenix framework is very well built on a solid core; it differs from other frameworks in that it feels more like a library, rather than a monstrosity that forces you to bend your application to its requirements. There's a lot of nice utilities that are easily pluggable and writing "plugs" yourself is rather simple as well. Phoenix has served me well when building microservices, too.
Elixir's biggest deficiency is that it does not have a proper type system. There is a very basic one, but it doesn't really help a whole lot. When working with Elixir, a type system is something that I miss the most. The way that Erlang & Beam VM are built makes it slightly easier to deal with errors at run-time, but catching stupidities at compile-time would still be immensely valuable.
It's a short project in which you create a homemade key/value store application. What's illuminating coming from elsewhere is how much it "just works" across the network and with multiple nodes including grace under failure.
I just started my Elixir journey late last year, and I've been using a combination of Elixir School[0], the Ecto guides[1] and a video course from Pragmatic Studio[2] that I picked up on sale back in December.
The video course was a mixed bag but mostly useful. I am also new to functional programming so it was helpful for getting my head around a new way of planning my code but there were definitely chapters that were painfully basic and slow. So if you're already more advanced, it may not be as useful to you.
That said, they did a good job of introducing certain key Elixir/Erlang concepts by getting you to build functionality "by hand" and then refactoring it into the standard library functionality, so you can understand how it works under the hood, while also learning how to use the built-in library modules in real code.
Elixir has some pretty important concepts around concurrency, state management, and process supervision that are worth exploring in detail before you dive in too deep.
In terms of personal projects, I always try to re-implement an existing project when I tackle a new language. Right now I'm working on a simple scraper/parser that uses a shared worker pool for concurrent post-processing of links scraped by the main thread.
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]
3. As you figure out which features you want, look up things on a need to know basis
And repeat that loop until your project is done.
As for learning material to help with step #3, assuming it's a web app, personally I found looking at the source code for https://github.com/thechangelog/changelog.com/ to be highly valuable. The Programming Phoenix 1.4 book is great too to fill in some gaps of a "self learner". Also Alchemist Camp is quite good for seeing how to do 1 specific thing or generally look for workflow / implementation ideas.
I like to get a "lay of the land" before I commit to a new lang so I read Dave Thomas' book on it while playing around with the language on small personal projects (same way I handled Ruby, read the Pickaxe book and did a few language experiments on my own). But YMMV.
I will say this- once you read the book it becomes ENTIRELY obvious to you who has not, when they ask certain questions, like "what is a sigil?"
After reading through the guides on the official website I went through the course on learnelixir.tv- basically the creator runs through each topic in the language in a series of videos in his code editor. I think it's $20 or so for permanent stream/download access and access to any new videos he puts out. (Maybe the creator is on HN?) I got most of my team up to speed on elixir this way.
I went through a bunch of exercism problems and felt like I learned a lot about the language syntax and control flow (which I think is pretty awesome).
However it doesn't teach you much about the concurrency model or Erlang/OTP, which I hear is the real reason for using it.
Lots of good suggestions here. You mentioned Ruby so I am going to assume some usage of Rails. There is a good presentation from ElixirConf 2019 about learning Elixir first before diving into Phoenix. Keep that in mind as you think of personal projects.
if you are a rubyist, I can't more strongly recommend watching this video, which has nothing to do directly with Elixir (in fact it precedes elixir by a couple of years) but if the topics that Bernhart (of wat fame) brings up resonate with you, then you will really like Elixir.
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. :)
>> ”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.
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'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 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.
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 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?
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
nivenhuh|6 years ago
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.
tyre|6 years ago
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.
pmarreck|6 years ago
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.
_asummers|6 years ago
anhldbk|6 years ago
histriosum|6 years ago
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?
josevalim|6 years ago
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.
fyfy18|6 years ago
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 :-)
bglusman|6 years ago
sbrother|6 years ago
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.
the_angry_angel|6 years ago
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.
S04dKHzrKT|6 years ago
https://github.com/SaturnFramework/Saturn
happy_path|6 years ago
How would you recommend to learn Elixir? And a follow-up: some ideas for personal Elixir-based projects?
neillyons|6 years ago
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.
emerongi|6 years ago
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.
[0] https://hexdocs.pm/flow/Flow.html
7777fps|6 years ago
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.
sbarre|6 years ago
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.
0: https://elixirschool.com/
1: https://hexdocs.pm/ecto/getting-started.html
2: https://pragmaticstudio.com/courses/elixir
plainOldText|6 years ago
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...
[5] https://elixirschool.com/
[6] https://elixir-lang.org/
nickjj|6 years ago
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.
nbap|6 years ago
After that, I would recommend taking a look at Elixir in Action from Saša Jurić
snake117|6 years ago
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!
pull_my_finger|6 years ago
innocentoldguy|6 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.
pmarreck|6 years ago
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?"
waylandsmithers|6 years ago
dragosmocrii|6 years ago
wefarrell|6 years ago
However it doesn't teach you much about the concurrency model or Erlang/OTP, which I hear is the real reason for using it.
matt_s|6 years ago
dnautics|6 years ago
https://www.youtube.com/watch?v=yTkzNHF6rMs&t=2252s
sandGorgon|6 years ago
josevalim|6 years ago
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. :)
ilja|6 years ago
alberth|6 years ago
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
josevalim|6 years ago
> 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.
playing_colours|6 years ago
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.
s3cur3|6 years ago
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.
elcritch|6 years ago
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...
bitscrapper|6 years ago
grimjack00|6 years ago
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.
ggregoire|6 years ago
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.
pdamoc|6 years ago
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.
dorian-graph|6 years ago
xyst|6 years ago
s3cur3|6 years ago
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.
hajile|6 years ago
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.
the_gastropod|6 years ago
- 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.
rkangel|6 years ago
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.
thomasfedb|6 years ago
neillyons|6 years ago
hopia|6 years ago
ta93754829|6 years ago
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...
vetrom|6 years ago
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.
7777fps|6 years ago
The new sort api seems like a significant improvement.
sysashi|6 years ago
Although finding green and red mismatches in pages of output of your data structure was fun :)
.. no
Thanks for the work on Elixir!
Grimm1|6 years ago
etuil|6 years ago
Zsolt|6 years ago
Please add your email to your profile so I can reach out to you. I'd like to chat and see if you'd be a good fit.
ctas|6 years ago
brintnc|6 years ago
derefr|6 years ago
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: ...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:
...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:
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.)pera|6 years ago
https://elixir-lang.org/getting-started/basic-types.html#ide...
bcardarella|6 years ago