I’ve been able to convince only 1 out of my 13 customers in the last two years to adopt Elixir/OTP. And this just for some minor side project.
They simply don’t want to step out of their mainstream, “well established” stacks. Java, .Net, PhP. 
Nothing else.
- while developers may have to learn Elixir / Phoenix, they won’t need to learn a bunch of other stuff like external background job managers, redis, latest JS front-end framework, etc as all these things are baked in (@sasajuric’s great talk, Soul of Erlang, (Youtube) tabulates these at the end)
IMO this is one of the main points that I always choose Elixir/Phoenix instead of another stack, you basically can have everything or almost everything inside your app without needing to use multiple third-party solutions just because of some limitation of the language.
In my experience, the cost savings of doing that is huge in the long run, and I’m not even considering the fact that we also have OTP, immutability, a declarative language, etc. All of this allows you to have a very small team for a relatively complex product and have a very simple and cost-effective deployment.
Right now I’m working on a node.js product, and there is not a single day that I see its code and don’t think “man, this would be so much easier, simpler, and resilient if it was written in Elixir” hahaha 
.
Unfortunately, the issue that I see with this is how to sell that idea, it is hard to get real concrete data to back that claim and a lot of developers and managers (IMO) simply don’t know better and think that having a system that you need to have a huge team and spend a lot of money in maintenance rather than improving the product is basically “how things are”.
Easy for you and me may not translate to easy for them. OOP is probably still the most suitable development paradigm for a team consisted of one or two very good guys and a whole army of junior developers. A lot of teams are like that.
This. Having it all in one package (also literally) saves a lot of money and time. Those can be used for the purpose of business/feature development instead of software development. And that is what matters to managers.
The devs concern can be dampened. Good React + Redux developers will find their way in a Phoenix Live View project quite fast and even faster when they used ImmutableJS. Devs with such background are quite common and they ate used to work with functions we use in the functional world (map, reduce etc). The latest Live View reduced the difference with React even further with declarative assigns. As piping will come to JS in the upcoming years the code will even look more the same.
So even when paradigma’s of JS and Elixir are miles apart, good React devs should be able to switch within reasonable (ROI) time due to similarities in syntax, ‘immutability’ and message passing (state, actions, reducers vs state, events, event handlers)
About ‘popular languages’
and what managers should be informed about in terms of risk.
One of my colleagues is a superb Javascript and Typescript developer. Has fundamental contributions is some libs used by large tech firms (Facebook for example). But he is clear about one thing: the churn in Javascript/Typescript/NPM ecosystem is way too high. The next best framework is always 12 months away (so support for your pick today diminishes after 36 months), populat libs break their API by full overhaul (so you need to rewrite a lot) multiple times in a few years. You almost need one team to develop features and one to maintain the current features (say…webpack..?). Not putting effort in keeping a project aligned with upstream for a few months can be lethal for a project (ROI wise). This colleague is still a JS/TS fan…but it’s his expertise after all.
We have worked for years (and still) with Python. I like the language for it’s easy to digest syntax. But it’s toolchain is rather antique and is has countless quircks. We have the workarounds, they work but they ain’t pretty. It’s eco system also like to break once in a while so you better stay close to recent. It good for a lot, but not so much for realtime apps (GIL didn’t help).
Both JS as Python can do all; and as many people only know Python or JS they make them do all. But that mostly means working with ‘workarounds’. afterthoughts on a fundament not suitable for it.
Java-land I haven’t seen last few years so can’t comment on it.
PHP/Laravel. Around for a long time and a lot of devs. Last year I had a quick look and it was a pleasant surprise as my last view was PHP 4. Seems like a option to consider.
Back to Elixir
While Elixir is quite new, Erlang isn’t!
There is a ‘law’ that says something like: the time a language will survive in the future can be predicted by looking at how long it exists today.
Erlang exists for a looooong time.
The reason Erlang/BEAM (in form of Elixir) rises is because it’s fundament is great for what is needed today. So maybe your best bet is to talk about Erlang and how Whatsapp and some other well known companies use it, and then mention the ‘modern syntax’ version of it like Typescript is a reinvented variant of Javascript (managers don’t need the nuance)
Ps. our greatest devs want composition instead of inheritance, immutability and message passing and less OOP cause of testability. Next project I gonna plug Elixir/Phoenix as it fulfills those wishes by nature. The JS/TS dev I mentioned earlier was already interested as he also saw the benefit of “less distinct moving parts”.
Hmmm, and? I was referring to myself in that paragraph, it is obvious that for other people that may not hold true…
But about the “OOP being the most suitable development paradigm”, personally I can’t agree… It is the most used, that’s for sure, but again, IMO simply because people know no better…
I work in a VC that acquires SaaS products, so we have a huge portfolio of SaaS products that uses a lot of different languages, infrastructures, etc, and from my experience with these products, it is clear to me that products that used a more declarative, functional and immutable language normally needs a smaller team, ship features faster and doesn’t need to spend too much time fixing bugs or fixing regressions.
But that is just my experience, maybe it is the exact opposite for other people, who knows 
I agree with you, for a small to medium sized and motivated team, functional programming is often more productive.
For large team that have very diverse skill level, especially if most are at the lower end of the spectrum though, a code base in a stricter hierarchy with lots of boiler plate might be better, a la java. At least some people believe so,
Of course, many teams are led by people who think they are super good but not really so. Then it will be a recipe of a big mess.
I’m with @LostKobrakai. They basically want to know that they don’t get stuck with some technology nobody uses, doesn’t want to use or can’t maintain in the future. Besides, if they haven’t heard of Phoenix they most likely don’t know anything about Elixir either. That explanation won’t help to convince a client because it doesn’t address any of their real concerns (risk/cost/people).
Even it was a technology question, I’d be careful using generic statements like in that explanation. There’s nothing project specific in there. No reason why it’s better for the projects you’d be working on and why it would benefit them. Basically everything can be said about other languages/frameworks.
Let’s look at the statements.
Easy to learn:
There are already a lot of java/vue/react/… developers that we can hire. Why should they learn something new at all?
From prototype to production in no time:
This will only be the case for really small projects. And those can be done with just about any technology.
Incredibly fast:
In most projects the language/framework choice isn’t the bottleneck when it comes to performance. And how much faster is it? Do we benefit from it? Aren’t other languages faster?
Concurrency:
Java/Go/…/… handle lots of connections as well. What makes this special?
“it’s better than Java because”…try not to say things like that. It will only cause bad reactions from people who like Java/React/Vue.
While LiveView is great, there are also other things to consider. Lack of component libraries like in Vue/React so you might have to write many yourself. In many cases you still need developers who know what they are doing when it comes to frontend (js/html/css/UX/accessibility). A lot of backend developers aren’t very proficient in those things. LiveView is also stateful. This means your deployments will be different. Form handling is still being worked on since it’s still based on stateless so if you have lots of complex forms that might be an issue. Replacing frontend/backend ‘specialists’ with full-stack developers can be a bad idea depending on the situation.
So the explanation doesn’t address any business concerns and it doesn’t convince me as a developer either. All I read are risks (not many people know it, new way of working) and no reasons why those risks are worth it. And depending on the project requirements Elixir/Phoenix could actually be a bad fit.
I think we’re in agreement here, but the tech leader should, IMO, be happy to justify, in detail, their choice of web framework or any significant technology choice to a mentor or investor and how it aligns with the budget and the nature of risk the organisation is willing to take on. Here’s what has shaped my opinion…
I’ve been a developer, tech lead, business founder, investor and business advisor (mostly in software technology for heavy industry), and I have seen multiple major car crashes from very smart tech leaders resulting in zero feature delivery for 18+ months 3-4 years down the track. (All due to overcomplicating things FWIW.)
I would absolutely be wanting a very robust discussion with any tech leader on the architectural and philosophical approaches they choose to take (particularly if I didn’t directly hire them), as poor choices can break the company.
That’s not to say I would impose my preferred tech stack on a tech leader - I don’t and I wouldn’t - but I do want to ensure they can explain the long-term consequences of their decision-making. The role of a mentor/investor/company director in this case is not to micro-manage, but to ask the hard questions of how things look 5 years down the track, what does the total cost of ownership look like and what drives it, how the understanding of the system will be maintained in corporate memory, how is complexity assessed, what range of support skills will be required, how developers will be onboarded, what is the level and nature of vendor lock-in, what kind of trade-off analysis is performed when pulling in dependencies, compliance with regulatory obligations, what level of independent thought has been exercised vs doing whatever FB & Google do with their multi-$B R&D budgets, etc. The framing of questions would obviously change depending on the context of the company.
If this is done in the right way, with mutual respect etc etc, it is the way to build two-way trust and understanding. You don’t just hire a manager and immediately totally trust them - that’s not how it works unless you have worked with them already for a number of years. And as a newly hired manager, you don’t just “know” what’s important to a particular company - going through the process of justifying and refining is part of the process of learning what’s important (and also whether the owners are generally sensible or not and whether you want to hang around 
)
There is a difference between supervision and oversight. And from an oversight perspective, it is their business to understand potential risks and costs introduced by a particular tech stack. As a common example, if you are raising funds in a public market, you must disclose potential risks specific to your company. This is definitely a board level and investor concern. Here’s an extract from the prospectus for a recent-ish software IPO (ASX:ICR). Vendor lock-in to Azure, a tech-stack decision, gets a special mention:
Investors require oversight (either directly for small companies or through a board of directors for large companies). For tech companies, this means satisfying themselves that the tech decision-making is in the interests of the shareholders and other stakeholders, and that means having these robust discussions with the individuals tasked with the decision-making. Directors leave themselves open to legal action from investors if they can not demonstrate that they have taken reasonable steps to manage key risks to the organisation, or if the risk profile of the organisation is materially different to that previously communicated to investors.
It’s no different to other roles - directors directly engage with the CFO to understand the risks & controls in place, and engage external auditors in addition to ensure the CFO or their regional representatives aren’t redirecting tax office payments into their personal accounts (or whatever else). And yes, they may tread on toes - e.g. pushing the CFO to implement a compliance system. They engage with the CMO to understand the marketing programme and often-times ask the next level down to explain how marketing spend represents value-for-money. They engage with the CPO and individual product managers to check-in on the implementation of product strategy. Internal control models (e.g. as described in Sarbanes-Oxley) encourage directors to regularly receive information from individuals below executive management levels to ensure an unrealistically rosy picture is not being painted by the execs.
People’s personal circumstances can drive them to do things that they may not do otherwise (e.g. a life event leading to well-hidden drug or alcohol addiction which then impairs the clarity of their thinking - maybe it’s just Australia, but I’ve seen this 3-4 times now), so this oversight, while more intense up front, does need to be ongoing.
Finally, for me personally, when I am in a tech leadership role there is nothing more demoralising than zero interest in tech strategy & approach from up on high.
Well this turned into a bit of an essay! Hopefully it’s useful.
While I don’t disagree with your analysis on a high level, it’s a bit one-sided. I and many others here have the history of objectively reducing expense of companies who were initially stubborn to adopt Elixir.
A lot more pages can be written about the benefits of a technology that’s explicitly made with the purpose to be quick to learn and achieve productivity with but when all the chips are down what truly matters is: have you contributed to the business’ bottom line?
And yes, yes I have, just by practically rewriting parts of their apps in Elixir and showing that it is objectively improving the entire status quo (vs. an Rails or Node.JS app).
Using your logic is the perfect way to never let any innovation flourish. There are objective, technical, often financial, and easy-to-write-down-in-a-report reasons about why is Elixir superior to e.g. Python, JS, Ruby on Rails, provided a few assumptions are correct (like: you don’t have to keep 50 devs busy to fill a budget which is sadly also a thing).
That somebody is not willing to see nuance and just puts aside the more recent thing because they don’t want to change the way they were doing stuff is fair; it’s their right and their prerogative. That doesn’t however mean they’re not missing out on legitimate benefits.
They chose to stick to their (previous) guns. That’s not the same as “the new guns are not that good”.
A lot of the arguments given are I think just slight rewording of the same thing: “we want to make sure the work keeps going regardless of who is doing it, and for that we want something that’s easy to hire people for”. And it’s sprinkled in with way-too-vague statements about a tech stack being able to stop them from doing business – whatever that means (and that “feat” is achievable with any programming language, Elixir included, because it depends on the quality of the staff and not the tech stack).
It seems they are just trading one risk (“we might not be able to hire a new dev if another quits”) for another risk (“let’s pay a fortune to an army of Java devs but at least we can replace anyone at any time”). Both are risks and I don’t see why the second one is preferable to the first one. Financially it also doesn’t seem to make sense either; you objectively spend more money in the latter case.
Since they are willing to throw money at the problem they might as well overpay their Elixir devs and promise them various benefits if they stay longer, no?
I don’t mean to be demeaning. But I see bias and inclination to prefer one class of risks to another. I remain skeptical that this is an objective assessment. It looks like preferences written in a perfumed language to me.
