How to convince others to consider Elixir?

A little background: the company I work for is doing some amazing work in the payment area. We work for a large acquirer, our biggest client.
They have needs for software that runs for longs periods of time, and simply cannot crash. It also needs massive concurrency and distribution. I’ve heard that there is this awesome VM suited just for that, but I just can’t quite remember the name :grin:

I need some ways to interact with the team + boss, to let them know that learning this platform will be great to help out our clients. Most of the projects there will have to be delivered inside the clients infrastructure, and they are going to be way harder to convince than my boss/team.

I showed off some of the cool features, like Erlang’s :observer, supervision trees and this massive, easy concurrency, but I feel I quite didn’t get there yet.

What are some actions I could take to get their attention? Team + boss + client?

4 Likes

Hello!

Check this topic

2 Likes

Here’s my post from the thread mentioned by Denis:

But since this is a slightly different question I want to mention two more things, culture (specifically, the culture of learning) and design choices, particularly in Phoenix.

The culture of learning is driven by the love we have for Elixir. Many of us have an insatiable desire to learn it and everything to do with it - because we want to - not because we have to (JS/browsers) or because we’re told to (Java/enterprise).

This results in much more advanced Elixir developers than you might get in other languages because it is a passion, not just a job that you want to forget about when it’s time to go home.

The second thing is design decisions by the Phoenix team, who, have opted to keep the ‘magic’ to a minimal. This means that when you use Phoenix you pick up things that are actually basically Elixir. This is unlike other frameworks which are more like DSLs and can be difficult or confusing to understand. This means by using Phoenix you become more experienced in the language itself and not just the framework. This too, is something I believe will lead to more experienced Elixir programmers in the long run and is an extremely smart move by the Phoenix team imo.

This is of course on top of all the things you (and others) have mentioned, the power of Erlang, the beauty of Elixir, etc.

I can’t wait to see the Elixir/Phoenix landscape a few years from now - I think it is going to be very exciting indeed!

7 Likes

One thing you can mention is that it is very easy for the erlang/elixir system to communicate with other languages/systems/etc. This means that it is perfectly reasonable to use erlang/elixir together with other languages/systems so choosing to use it does not mean you have to completely migrate. You use it for the parts of the system where it best suits and leave the remaining parts as they are.

This is a typical way erlang/elixir gets into systems and also many production systems do use multiple technologies.

There was an Erlang User Group meeting in London on Thursday, http://www.meetup.com/erlangusergroup/events/229789989/ , where Dan Macklin from Bet365 talked about getting erlang into Bet365. I don’t know when the video will be released but when it does it is well worth watching.

7 Likes

I’d like to point out a great article about this in The Erlangelist.

Thanks for the info! I’ll keep a look out to that video.

4 Likes

@nubunto I’ll share the story of how we ended up in a place where all new (internal) projects are being written in Elixir. The journey started about 18 months ago. By this time I had already given two or three internal tech talks about Elixir. My team was tasked with writing a service that would ultimately be used by a customer, though not directly. The flow looked like customer runs CLI thing => hits web service => web service asks us for authorization. Because the customer is ultimately waiting on our response, latency was a key issue. I realized this was my chance to broach adding Elixir to our environment.

I prototyped the service three times: once in two of our official tech stacks, and also in Elixir (using only Plug at this time since I believe Phoenix was in its relative infancy, and we didn’t need any UI). I then deployed each version to Heroku’s free tier and began to hammer on it from an EC2 machine in the same Availability Zone as the Heroku dynos. I then retested each with Heroku’s high performance dyno. One of the official tech stacks had difficulty meeting the (admittedly absurd) latency SLA at all. The other could meet the median and average portions of the latency SLA, but not the 90th percentile (due to global GC locks). Elixir on free Heroku tier exceeded the latency SLA. This was enough to get us discussing Elixir as a viable option.

We then weighed the relative business and engineering costs necessary to bring one of the other solutions up to meet the latency SLA (90th percentile of 12ms, including network transport time). Given our organizational competence in the other stacks, we opted to go with one of those, despite the greater engineering and business costs. But Elixir had its foot in the door!

A couple months later, I was informally discussing Elixir/Erlang with some SysOps folks, because I was having difficulty with an exrm-generated init-script to be fully Debian-compliant so I could manage an Elixir service via Puppet. SysOps’s reaction was basically, “Oh, Elixir is just Erlang. Oh, it’s a dependency-free tarball, and I don’t have worry about OS-package conflicts between it and, say, RabbitMQ. Oh, and we can manage its config via Puppet (via conform-generated .conf file). This is way easier for us to deploy and manage than either of our other two official stacks. Grassroots-approved!” I wrote plug_statsd so SysOps could monitor uniformly with other applications and began using fpm to generate OS packages instead of tarballs.

By this time I had also generated interest in the language with a couple other devs and a couple people in SysOps, assuaging the “It’s hard to find people” trope. With enough line folks in dev and SysOps on-board it was a relatively straightforward to jump to “All new (internal) projects in Elixir.”

We’re nearing a year in production for the first Elixir service, which has been great for me. The only time I’ve had to even think about the first production service is when an upstream vendor changed their not-SemVer API in a .z release :rage:. I’ve even had to ask coworkers if they still use the service because I never hear any complaints (they do). As our team has grown, I have opted for growing Elixir talent rather than finding it, especially since that ultimately increases the size of the Elixir community.

We also have a full Continuous Deployment pipeline that builds releases, OS packages, publishes packages. Puppet configures with whatever credentials SysOps establishes (and they can change them without my involvement), deploys the latest packages, ensures the service is started. This uniformity makes staging => production super easy.

12 Likes

@jeffweiss awesome story! Thank you for sharing this.

This week, the company I work with allocated me to a new project for a client that was (literally) a copy of Stripe. We had our own payment gateway, and the client (which is a large company) has a contract with Sensedia, so we needed to develop this internal API as fast as we could.

I demonstrated Elixir (and Phoenix) to the client, who was also a developer, but mostly working with management, and he got way too excited. I talked to Erlang’s scalability, performance, distributed and fault-tolerant properties and to Phoenix’s productivity, and he was baffled.

Unfornately, since this project would run on this big company infrastructure, they crossed Elixir, for not being “Java + Oracle DB”, their default stack. This makes me really sad, since their systems require a lot of features that Erlang can offer, for free, and they are spending millions (really!) to monitoring libraries like Inspector and tools like Java/Oracle/SQL Server.

Well, things are the way they are. I’m betting my future startup in Elixir, and I couldn’t be more confident.

3 Likes

A post was split to a new topic: Elixir/Phoenix with Oracle (database)?

article: Elixir and Phoenix: The Future of Web APIs and Apps?

1 Like

HI Jeff - could you share a bit more how you were hitting 12ms with Elixir? I am in the same boat as you were. Evaluating Elixir & Phoenix to run on EC2, but trying to hit 20ms with a lot of load. I can’t seem to get Phoenix to respond in less than 20-30ms even for a simple hello-world type of app. I’m at a bit of a loss as to where to look next. Any help you could provide would be greatly appreciated.

4 Likes

A good case seems to be a high-load not too complex Ruby app that is consuming considerable computing resources. There it’s very easy to make the case given that porting cost could in some cases be less then the hosting bill savings (over 12 month period).

2 Likes