It's easy to find people talking about why they took the gamble to switch to Elixir. I'm interested in those who have tried out Elixir in production (or a serious prototype, not just dabbling) and then decided not to use it. Why not?
I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:
I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.
I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.
I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
> The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.
The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).
This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.
Scala maybe, but it has its share of problems, alas. On a purely features level I'd definitely be looking for something with null safety, disjoint unions, pattern matchin with exhaustiveness checking, local type inference, and parametric polymorphism (ie. generics). These are what set a modern, nicely typed language apart from the more constrained, frustrating kind that caused many to escape to PHP, Ruby, Python, and now Elixir in the first place. We need a richer experience beyond that though in terms of ecosystem, compiler performance, teaching materials, etc. in order to really drive things in that direction though and get more back-end devs on board. Obviously something in our approach is not working - and it must be partly our failings. It's going to take a while to turn the ship around, but I still have hope!
In my frustration while writing my comment I'll admit I was a bit weaselly there and didn't really cite anything. The Akka.Typed[1] project is working on type-safe actors, but looking at it again I'm not sure how or if they can do hot-reloading or ensuring that you can soundly migrate actors in-memory before starting a deployment. That would be super cool to see. Maybe something for Pony to look into? If folks know of any academic PL research on this front I'd be very interested. But again, I'll reiterate that it's a use case that lies at the very extreme end of our industry.
Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor. If you "guess wrong" on a language you're looking at a multi-million dollar rewrite down the road which is an unacceptable risk. It's also very difficult to find staff or contractors who are familiar with new or unpopular tech.
Basically any industry that deals with "real money" or "life and death" intentionally does not follow developer fads.
Well Erlang Solutions supports Elixir in a major way. Goldman is running a lot of core critical systems on Erlang (supported by Erlang Solutions as far as I remember).
Well thats a very random question in my case "we" are charging 400 USD / hour and have to turn away clients because we are at 100% capacity. (this has very little relevance to Elixir though)
I believe Klarna (dominant payment service provider in Sweden, handling >$10B/yr) is starting to do some stuff in Elixir (having already invested heavily in Erlang).
Started? I'm quite certain their entire API backend runs elixir. I've been an early user of their public APIs for many years, so I got curious and asked the developer in charge back then.
You can't hire or rent devs that know Erlang without a multi-month search in most markets. This is a non-starter for most businesses.
Train them on Erlang yourself? Why? Any possible productivity benefits offered by Erlang over a more mainstream option are dwarfed by training and hiring costs.
Nobody gives a shit about hot code patching in real business systems; the telco switch architectures which demanded such features are basically bonkers and unnecessary in a packet-switched world.
Yes, I understand, I was just wondering if Erlang would be considered a "proven language".
From my (limited) Erlang experience, Erlang & Elixir have the same core functionality. Elixir has a "nicer" syntax (I prefer Erlang's syntax but most devs I've talked to like Elixir's).
So if Elixir isn't proven but the concurrency model & programming paradigms make sense, maybe Erlang is a good choice.
> "I was just wondering if Erlang would be considered a "proven language"."
Erlang is proven in production for server and telephony apps.
> "From my (limited) Erlang experience, Erlang & Elixir have the same core functionality."
Depends on what you mean by 'core functionality'. If you mean the functionality provided by Beam VM or OTP, then there's a case to be made for that. However, the library ecosystem for Elixir is separate from the one for Erlang.
To use an alternate example, Java is definitely a 'production ready' language for enterprise software. However, if I write a new language for the JVM, it's not automatically 'production ready'. In most cases it's the library ecosystem which is under evaluation, not the platform the language runs on.
Just saying, but so far, there have been more critical bugs in erlang solved due to the Elixir community than Elixir critical bugs solved... so well...
Erlang has been in use for decades, so yes. For many years, and possibly still true, nearly every phone call in the world went through Erlang code. Yes it's proven.
Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor.
The 'banking industry' is huge. While what you say is true in many parts of the banking industry, I also know people in the banking industry for example who write and use an in-house DSL written Haskell for their day to day work.
An in-house DSL is madness and could only be achieved behind management's back. I hope the documentation is damn good. I bet they'll be over-paying the jokers who wrote it (as a form of job security!) for the next 20 years.
It's also worth noting that, VocaLink, one of the well-known payment systems company do use Erlang for their products. I have also seen that Visa/Mastercard has been looking for Erlang developers as well.
But Erlang and Elixir are not the same thing. Erlang is proven in a major way thanks to telecom industry. That they both use the same VM is not enough.
Erlang and Elixir are way more "the same thing" than, for example, Java and Clojure are. The summary that "they both run on the same VM" is very general and elides a lot of details.
Elixir, on the one hand, is a new library and tool ecosystem. It's hard to compare libraries, but tool-wise, Elixir wins simply because it has them. Erlang has been underdeveloped in this aspect for years and it's not changing very fast.
Syntax wise they are pretty different, but it's trivial to use Erlang libraries from Elixir (not as easy and not always possible the other way around) and there's not feel that they're designed with different principles or feel foreign. Moreover, some standard Elixir APIs are simply old Erlang libs dressed up in slightly better clothes.
On the other hand, it's just the syntax which differentiates Elixir (the language, not the ecosystem) and Erlang. Only the compiler frontend is new in Elixir, from a certain point (an Erlang abstract syntax tree) it's Erlang all the way down to the bytecode/VM-executable code level.
I love elixir, but it's just a language. There are other great languages, too. Use what fits your brain. Don't listen to what others carry on about. The only downside I can see for me is that there are fewer, less battle-tested libraries available as compared to, say, ruby. The most unexpected benefit of getting into elixir has been the community--it's a positive place to be, and I feel it has made me a better, more confident programmer. <3
One of the great things about using different languages on my off time is that the number of things that fit my brain has grown over time. It doesn't actually take that long for an experienced polyglot programmer to pick up a new language.
I think use what fits your brain is the kind of advice that sounds good but does most people a disservice. At work use what allows you to ship high quality code, on time, within the business constraints that you have. But you'll have much better options in your career if you take at least some time to expand your brain so more things fit in it.
I guess what I meant by "use what fits your brain" is more along the lines of, "try a bunch of languages first, then use the one you like most". Without experimenting, you'll most likely be lulled into thinking your first language is the one that fits your brain best. I would disagree with the notion that a language fits one's brain after you've picked it up. I really don't like javascript, for instance, and I've used it quite a bit.
As someone who spent a long time in Ruby land, the last thing I want right now is another dynamically typed language.
I'm a big fan of Erlang and OTP, and really wish for that style of concurrency, failure tolerance and distributed computing. For me, the lack of static typing in Elixir struck me as a missed opportunity from the outset. The Ruby-like syntax isn't enough to change the game for me (I find it significantly less attractive than Ruby, but that's not important), even with macros.
Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm sure it's great. Just not for me.
Go is what I'm using now, and I've been playing with Rust and will probably start using that when I have a new project. I've been using Haskell for some side projects. I like OCaml a lot, but I won't touch it until multicore support lands and matures. For web projects, my plan is to transition everything from JavaScript to TypeScript, precisely for the type system.
No more dynamically types languages except for scripting.
Deployment is by far the biggest pain point I've seen in new Elixir developers. Developers use Mix in development, but then build releases using Distillery for production. There are a few gotchas and pitfalls that almost everyone falls into when using Distillery like using `System.get_env` and forgetting `server: true` in their `prod.exs`. Hot upgrades can also be a source of a lot of confusion. Configuring distributed clustering in production can be tricky especially if you're running on Docker/Kubernetes/etc.
That said, I built https://gigalixir.com to try and help with some of these issues and improve the deployment story for Elixir.
We are using Elixir in production for a site with traffic that can spike in a short period of time.
Elixir has helped us reduce our costs by 1/3 and improve our API response times from 50ms to 5ms. (Ruby -> Elixir)
Using erlang/Elixir processes forced us to reevaluate the way we handle state and were able to find many ways to optimize.
I believe our code is now more organized, extensible and powerful. Our infrastructure is also more complicated, but much more fault tolerant as we have fallbacks for fetching data etc.
Deployment was pretty terrible but a simple scaleable solution with AWS is build with a docker container, push to ECS and launch ECS + ElasticBeanstalk and you're good to go.
All my new server-side code is in Go (where all my old code was in Elixir) because I wanted something I could build locally and deploy easier. The deployment story for elixir is... substantially worse than ideal, for, seemingly, no reason at all. At the time I was writing the deployment scripts, not only was the hot-code-replacement not going to work, even AOT compiling to .beam files was broken, with multiple 3rd party tools not helping.
Elixir seems to have better abstractions at building CRUD apps (and websockets) than Go. Are you building CRUD type apps? Have you writing lots of SQL vs using ecto to be painful?
Not exclusively CRUD apps, but some. I've not minded the DB work I've done so far, but I also don't mind SQL. Changesets are a smart API, but fundamentally aren't much different than normal SQL. Ecto is nicer for loading lots of joined data, but... eh. Hasn't bothered me not having it. So I'd be hesitant to say Elixir has lots of amazing APIs -- good, but not indispensable.
We wrote a few small services in Elixir at work and I loved it. I had been using it at home and reading all the books, and would have been happy to commit 100%.
However, I don't think anyone else was getting excited about Elixir, or more broadly about functional programming. When it came time to choose a stack for a much bigger project, Go won out. The only specific complaint about Elixir I'm aware of is that ramp up time would be too long every time we bring a new dev onto the project. In hindsight I don't think Go is any different in that regard. A Ruby/JS dev either needs to learn pattern matching, macros, list comprehensions, and a bit of OTP for Elixir, or they need to learn static typing, pointers, goroutines, and idiomatic error handling for Go.
Personally, I'm happy either way. I'd still probably choose Elixir if it were my choice to make, but I'm loving Go too.
I'm pretty strongly on the Elixir train, but here's where I see its greatest weakness:
On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.
In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.
For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.
I don't want this to feel like an ad, but https://gigalixir.com should help in this area. Its a platform-as-a-service, like Heroku, but it's designed to encourage stateful application servers by not doing daily restarts and supporting hot upgrades. Disclaimer: I'm the founder.
Right now, the servers are on Google Cloud Platform in the us-central1 region. It's in multiple availability zones for reliability.
I highly doubt the service will be discontinued ever since traction looks good and we have plenty of funding, but Gigalixir and Heroku are almost interchangeable. The only difference really is that Gigalixir doesn't require a Procfile. However, if you fallback to Heroku, you'll lose clustering, hot upgrades, etc.
I've been reading HN for years, and this is the first time I've seen/heard of Elixir.
Sample size of 1, self selected, your mileage may vary, things in the mirror are closer than they appear. That is, it isn't really meaningful as a data point in isolation.
I only clicked this link out of morbid curiosity, on why someone would make such a presumptuous statement. Put another way, the question asked is heavily loaded. I was more interested in the discussion around the statement, to see what people thought, than the content of the question.
You may have what you and others consider the greatest thing since sliced bread. And you might not fathom why others would not see it that way. After all, it is the greatest thing since sliced bread. It is a dessert topping and a floor wax (obligatory SNL skit reference).
Even with all this, the criteria for success, oddly, rarely has being "the greatest thing since sliced bread" as part of the core elements of being successful. You don't need to be superior to be successful (though I am not stipulating that Elixir is superior, I've never seen it, used it, etc.)
The question is why would people choose this over others? What benefit would this language provide that others simply cannot?
I've used many languages during my professional and educational life. I've never seen one that was universally appropriate for all tasks. I some that fit the majority of tasks I worry about, very well. I've seen others fit very poorly. I have no opinion on Elixir, other than to note a small vocal group wondering aloud how anyone could not use it.
That is a very lengthy reply to a very simple observation :) If you are genuinely curious why people are interested the short version is all the power of Erlang VM made available via way more conventional syntax. There are a lot of very unique properties of BEAM (Erlang VM) that are truly not available elsewhere:
preemptive scheduler,
per process GC (no STW crap),
all the OTP goodness for dealing with failures,
node transparency
hard to list all the pros to be honest
It's not that big in English speaking countries either. Of the devs I've worked with in the past, I can only think of one that knew what HN was. There's a large majority of career programmers who couldn't care less about the latest trends.
Erlang and Elixir are both fine languages, but the BEAM is slow and not suitable for anything computationally intensive. Extending your program whether via NIFs or Ports is a PITA. It's great for anything requiring many active connections like front controllers and P2P, but outside of that you're better off with Clojure if you want an FP with immutability IMO. I think that you need to be working on a niche concurrency-focused application, or have engineering manpower to burn, to justify using a different language for such a narrow case. Erlang library support still is not very good except for, again, concurrency-focused ones (gproc for instance).
Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language. Maybe once Python starts to be obsolete I'll switch but in the meantime I can't afford spending time learning something new just for the sake of it.
That's a really interesting (and, in my opinion, negative viewpoint)
I have been a Python developer since 2006/2007 and every time I depart to another community for a while, I return with a ton of new ways to think about problems. Not only that, you'll usually have a newfound appreciation for things in Python you might not have really cared about before (eg decorator syntax)
- Becoming a Rails developer was a game changer. The Pythonistas tout it to be 'magic', but it's really not. It's easy to understand what is going on. Once you use a tool like Rails in more advanced situations – every Python web framework looks like a horse drawn carriage.
- On a related note, reading Eloquent Ruby was one of the most epic nonfiction reading experiences of my life. After reading that book, I rarely see "programming magic" to be magic anymore. I understand it all. A lot of the knowledge from that book translates well to Python too, since Python and Ruby are very similar.
- Learning Clojure and using it day-to-day at FarmLogs has made me think more functional than I did previously.
It's usually not just the language that is going to open your mind - but the frameworks, tools and communities that grow around the language. It's like visiting a new country. You're gonna love certain customs and dislike others.
Anyway... saying you don't have time for something that will open your mind and make you a better programmer sounds like a grumpy old man who's missing out on the world.
Despite the naysayer replies you are getting, I understand this viewpoint. I'm also a Python developer, business owner, and family man...very little time for learning extra things. Right now, I have my hands full keeping up with changes/frameworks on the front-end, which is where my customers will benefit from improvements. Elixir is on the fringe for me, something I will keep an eye on, but won't seriously consider using unless it has significant developer mindshare in 3-5 years.
So, yes, learning is good. But we are still finite beings with limited time. Having priorities about what you will spend your time learning, and choosing Elixir to not be one of those priorities, is a legitimate stance. Thanks for sharing.
This is exactly my point. When I was a teenager with lots of free time I loved experimenting with new languages and stuff. Now I am employed and the little time I have outside of work I'd rather spend it with my friends and family instead of tinkering with tech. I do enough programming at work, I don't need even more of it when I'm home.
I wouldn't stop learning new languages. They are just tools, and knowing several of them lets you better judge how to face a new project/problem. I was (in fact, am) a happy Rubyist, but had to start working with Node and learnt to love the beauty of event-driven programming and prototypal inheritance. Now I'm learning Elm, as I'm quite interested in functional programming and event sourcing. I wouldn't say that any language is better that another, but knowing some of them and the principles they are based upon is helping me evolve as a developer and changes the way I code, regardless of the language I choose for a certain project.
I've come to pretty much the same conclusion as the OP. I used to love learning and trying new languages and I agree that learning things like C and Lisp and Haskell definitely made me a better python programmer. However over the past few years I've decided that python, while far from perfect, is the only language I've found that is good enough for everything I want to do. And more importantly I've realised that learning new languages is not the best use of my limited time. I'm much better off studying a new domain or practical application which I can apply python to than I am learning a new language do to the same thing I'm already doing in python.
I would highly recommend you not hold true to this. Learning encourages growth especially in languages like elixir and erlang which offer a functional view of how to approach problems. This can lead to better use of functional Python functions and methods such as map, lambda, etc.
Whether you use the other language doesn't mean there is no benefit to learning it
> Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language.
This is a very limiting view of the programming space and world in general, hopefully with time you will understand that learning a new language will only help you to get better in your old language. You don't need to invest years in a new language to get the gist of it.
I think this a great discussion topic.
I am really glad that everyone loves elixir on HN but I would like to hear both sides to analyze the weakness and strong points of a given technology.
This makes more a balanced discussion instead of just praising a language.
Honestly I would personally enjoy a more technical scrutiny of a language / framework, especially from a technical site like this one.
Does anyone have a good write up on something like this for Elixir?
The deployment can be difficult to automate especially if you are attempting to inject application properties at runtime.
There are solutions out there,though documentation may not cover every use-case, especially if you are deploying to something like AWS or GCP (Not everyone can adopt Docker just yet).
The Hot-Upgrade is a great idea though you will have to do your research to integrate this with your Cloud Provider.
Overall I'm betting adoption will be niche, and primarily via Teams coming from Rails. Until a major cloud provider starts offering native support + the community grows to a sizable percentage, it will be slow to catch on.
We are hiring Elixir developers at talkjs.com and find it to be a very easy way to interest good developers. A lot of people have been hobbying with elixir and want to use it at work but can't in their current job. Also, currently it is hardly ever someone's first language so we pre-select to relatively experienced programmers.
Why do they have to know the tech before? A good engineer can always learn new tech and I think as a developer who belongs to a company who uses Elixir in production, most of my colleagues who use Elixir didn't know about it before getting hired.
And if they happen to love the tech, which seems common with Elixir, then they might also want to stick around longer. Uncommon technology can give a team cohesion.
Learning languages and using them to develop an actual production-grade product are two different things.
Pick something proven.
I worked in a Scala shop and people spent tons of time flailing about arguing over syntax, dealing with bad IDE plugins / slow tools, etc. They'd have been better off just sticking with Java.
Elixir and Erlang have similar symantics, compiles to same byte code. You can use any Erlang library in Elixir without any overhead, all the tools (debugging, profiling) which works with Erlang works with Elixir.I don't see why you can use Erlang and not Elixir.
If it slows the team down significantly and that speed is not regained in either performance or development time, then I personally would not hire developers to learn X new language.
I doubt everyone chomps at the bit on a Saturday morning (for most of them) to remind others on the internet that, yet again, there are no silver bullets.
Elixir is just an AST transform for erlang/otp. I like erlang and there are features that I wish it had sometimes, but elixir couldn't be further from what I'd come up with if I decided to fix it myself. It takes all the bad parts of lisp, shoves them into a bad ast format, and crunches it all down to beam code. It's just a terrible implementation of a terrible idea.
I am actually moving components of my apps away from erlang to f# to shield it from the destruction of beam that elixir will bring about.
I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.
I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.
I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...