Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why isn't Phoenix/Elixir more mainstream?
91 points by HerrBertling on Sept 29, 2023 | hide | past | favorite | 127 comments
Hey all!

I've been a frontend developer for years, primarily working with React and Vue, connecting them to REST or GraphQL APIs. Lately, I've been diving into Phoenix/Elixir, and I've been intrigued.

From the docs and examples, Phoenix seems to offer a significant amount of built-in functionality, potentially providing a more streamlined and robust approach than the separate backend/frontend architectures I've been using.

However, I know there's always more to the story. For those experienced with Phoenix/Elixir:

What are its pros and cons compared to popular frontend frameworks?

Why hasn't it gained as much traction as other frameworks?

Appreciate your insights!




I have been a big advocate for Elixir for 5 years before switching off.

My takeaways: love José Valim and the team and the libs they produce. The team is always humble and helpful and produces high quality content in both code and documentation.

Why I stopped using Elixir: I was using Elixir obsessively as a performance chasing tool, but then it just didn’t fill the gap properly:

1. Python (or other massively used language) is preferred for large SaaS apps where performance doesn’t matter. As an engineering manager, I can go out and hire a huge team instantly for Python.

2. Rust is much faster and not super difficult. When I ran out of optimizations for Elixir I found myself dropping down to Rust. Then asked myself why even use Elixir?

With those two points, Elixir, like Haskell, changed my programming mindset immensely, but as a professional context, quite frankly you have to use what you can build a team with. Elixir has very few engineers to source from.


Regarding #1, as someone with managerial experience, I'm really tired of hearing, "We can't find enough Elixir resources".

That's a cop out excuse. On the Discord, Slack, and Elixir forums, there are hundreds, if not thousands of devs looking for work.

Often it is lamented that nobody can find enough Elixir engineers, but they also seem to have a very hidden agenda here. Executives just want the job done, and Elixir can do it, but all too often the trope of not finding enough resources is lauded about as a reason to stick to LANGUAGE_MANAGE_HEARS_ABOUT_MOST (Python, JS, RoR, et al).

Everyone also only wants Super-senior-staff-principal engineers for Elixir roles, with 20 years experience, and can live code a project to perfection in 3 hours. Maybe realize that as the community grows and engineers adopt to the language, it's ok to bring in early-careerist resources, or others who just are getting started out. Give them a book, some assistance, and keep working with them, and it doesn't matter who knows it at first, in 6 months you'll have a rockstar team.


It also goes the other way.

If you're a savvy dev and a search like:

https://www.itjobswatch.co.uk/default.aspx?q=Elixir%2C+Rust%...

comes up with zero for Elixir, you don't sink time into it.

If nothing else, you know that the low job availability puts you in a very weak bargaining position.


This is the kind of attitude that would have seen Java jobs proliferate lol


The harsh reality is that when it's your livelihood, and not just a hobby, you HAVE to make these calls, whether you like the answers or not.


I mean, Elixir is definitely not a replacement for Rust. I imagine it as being closer to Node, Python, or possibly Java. And even then, it's a wild comparison, because of the way Actor Model concurrency is weaved into BEAM languages, in a way that no other language does.

For perf optimisations, you have Ports or NIFs (irc), where Ports are just knowingly volatile processes, and NIFs are FFIs, which is an almost universal feature across all languages.

But I suppose your experience is based on use case. And I would agree that commercial BEAM language experience is generally thin on the ground, if you're role is to build an engineering team (though I can't imagine Rust expertise being that much more abundant either).

One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards. But ignoring that (especially with vendor lock in issues), I often wonder why Elixir hadn't put a larger dent in the popularity of Kubernetes. Because BEAM's approach to managing multiple services across machines seems both much more powerful, and dev friendly.


> One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards

IMO, that's a misconception. They work at different levels and I wrote a more in-depth explanation here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

Although I agree the sentiment plays a role on adoption, because many ask "why Elixir when I have k8s", while in practice, if you like k8s, you should enjoy Erlang/Elixir. They apply similar principles at different scales.

So I don't think we could have made a dent on k8s, but rather, we should have positioned ourselves earlier within k8s strengths. :)


The issue I found myself in is that I agree with you, that Elixirs Actor paradigm is completely different and not comparable to other languages, but at the end of the day, very very very few applications and apps that startups work on need that. Most apps now are trending towards serverless. And most of the world gets by without the “operating system in an operating system” approach of BEAM.

Rust can be massively concurrent without Actors and GenServers.

So while the Actor model / let it fail approach changed the way I think, at the end of the day I found the traditional paradigms to actually be faster and cleaner to the real world applications that made me money.


It's worth noting that the pattern you describe here is an emergent property of programming languages that changes with the era:

http://www.paulgraham.com/pypar.html

Sadly, the culture of programming language choice in commercial contexts has changed a lot in twenty years, but you can replace python with rust or elixir because programming language choice is a good proxy to understanding insight, intuition, and intelligence.

I like python, but if the broad preference mattered, we'd all be running J2EE apps today. My reasons for choosing python around Y2K were as philosophical then as they are now.

Where your argument goes awry is that what matters is how the programming language catalyzes better interdisciplinary team communication. Code tells a story that, the easier it is to read, the clearer the story gets, and that pays unforeseen dividends in development, deployment, debugging, and distribution.

Computer optimization is straightforward by comparison to scaling human commercial endeavors.

“Programs are meant to be read by humans and only incidentally for computers to execute.”

― Donald Knuth


Where your argument goes awry is that this discussion is about Elixir. The points you make I did not see happening in the Elixir community so I left even though I was a staunch advocate for years.

Programs are meant to be read by humans. Which is why Python and the bunch are so widely popular across foreign contexts.

Elixir is hard in that context because it introduces a lot of paradigms.

I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.


> I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

Most of the "scary" parts of the BEAM aren't surfaced when using Phoenix. I don't think you are being terribly honest here. Working with Elixir/Phoenix is no more difficult from a academic aspect than working in Python/Django or gasp JS/Typscript/(Front-end framework du jour.)

> There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.

If you say something like Go or Python. I'm going to scream, lol. It's just isn't true. Phoenix was voted the most loved web framework in stack overflow's 2022 survey, Elixir was voted second most love language after Rust. A large percentage of the survey takers only had 1-3 years of experience.


Good point. I can relate.

I worked in Ruby on Rails and our particular culture of Rails was not the purity that DHH encourages, but a kind of hipster collection of things like Cucumber, where the intent diverges from reality. That is, we understood the design intent of the DSL barrier-lowering interdisciplinary facade to non-technical people writing tests.

However, that is not what happened in reality. What happened in reality is that only techs wrote Cucumber tests and they struggled mightily with abstractions that had good intent, but bad ROI, given their misapplication.

The constant cacophony of unforeseeable DSL interactions was that team's annoyingly persistent foot-gun postmortem.


For a Phoenix application, a Ruby on Rails developer will be able to pick it up pretty fast. Usually just takes one or two pair programming sessions going through the full MVC flow with test-driven development and they're good to take on most tasks. Then reading up some of the official Getting Started Elixir docs fills in the gaps, particularly understanding how a Process[0] works, working up to Tasks/GenServers/Supervisors under the Mix and OTP section.

For hires that already know Elixir, I've found the talent pool to be way above the average (and expensive). They're usually senior devs that fell in love with Elixir, wanting to move away from their previous tech stacks or have already worked at an Elixir shop.

[0] https://elixir-lang.org/getting-started/processes.html


The discussion is why isn’t it more mainstream not is it good.

Like you said it’s mostly senior expensive engineers. They are really good, but is it worth it? Do 90% of startups need it? I have had success hiring younger inquiring Elixir engineers also, but the question is about why isn’t it mainstream not how to find a diamond in the rough.

If you are running a company today the fact of the matter is Elixir a a executional Risk and the Reward the risk gives clearly isn’t worth it for most startups or else it would have higher adoption.


Really appreciate your focus on economic reasons. That indeed makes a lot of sense.

I guess the gamble to use Elixir/Phoenix only pays off in certain circumstances and if your business grows in such a way that you can simply afford to hire more expensive devs in later stages of the journey.


I would second his opinions and take it a step further ... people here will debate tech stacks til the end of time but in the grand scheme of things picking a tech that has a much smaller and more expensive talent pool could be a scenario where that choice is a death knell for the project (could be, not will be). The low adoption rate also means more abandoned libraries, less variety of libraries and possibly having to DIY things. These all add time to a project on top of a learning curve (which will vary per person) which make it more expensive.

I'm not advocating always pick something with the lowest $/hour rate. There are a lot of other choices out there that are not going to have risks around technology choice.

Long term maintenance is a concern too, not of Elixir, of the apps built with it. When that app goes into a maintenance mode (still providing value just doesn't need new/active development) the devs will likely move on to other work/companies. Now to do support work you have a small+expensive talent pool that doesn't likely want to do support work.

If you're a fan of Elixir, don't take this as me saying "no", I really like the things I learned (and continue to learn) working with it. Its just trade-offs that mostly are on managements shoulders. The developers advocating for it take no risks really.


This is an approach I strongly believe in.

For 99% of things, language performance doesn't really matter (it's usually cheaper to just scale up). So you might as well focus on developer experience and hire-ability.

For the 1% where it does matter, drop down to something like Rust, and use the developer-friendly language above as glue.

You see it a lot in Python, where the performance of the runtime itself is kinda crap, but it doesn't matter because it's very developer-friendly. It became the #1 language for high performance data science, thanks to libraries that use C and stuff under the hood.


Elixir doesn't offer an easily benchmarkable performance boost the way Rust does.

It does offer a boost, but in the form of system reliability in a concurrent environment. This kind of advantage is seldom properly evaluated until AFTER you have a disaster ... by which time you are typically committed to different stack.


> Elixir has very few engineers to source from.

this : http://www.paulgraham.com/avg.html comes to mind.


I guess my point would be that Rust is also could be considered an esoteric niche language with a lot fewer engineers than Python, but I would choose Rust over Elixir because of the benefits.

I think PGs advice really depends on the founding team. Now it’s quite common to have only semi technical founders that make an engineering hire instead of the founder being an engineer, because languages like Python and JavaScript have commoditized the initial CRUD aspects of launching a product.

If your product is more technical and low level it makes sense, but if your building a HTTP SaaS app that connects to a database then chances are the difficulties and differentiation happen on the Product/Design level, and much less so on the engineering level unless you make it big.


"A false dilemma, also referred to as false dichotomy or false binary, is an informal fallacy based on a premise that erroneously limits what options are available. The source of the fallacy lies not in an invalid form of inference but in a false premise. This premise has the form of a disjunctive claim: it asserts that one among a number of alternatives must be true. This disjunction is problematic because it oversimplifies the choice by excluding viable alternatives, presenting the viewer with only two absolute choices when in fact, there could be many."

1) There's plenty of Elixir engineers, and most of them specialize in web development or a domain thats web dev adjacent. Python is used for everything, with loose conventions on how to program in each domain.

2) Rust maybe faster than Elixir... but what about things like concurrency across multiple nodes and fault tolerance. Fearless concurrency, etc. also, it's really not that hard to create NIFs in Rust. It's really hard to do the above in Rust.

2.a) for most kinds of developement where both rust, python, and elixir could be used to solve a problem (web dev/data science)..... speed is probably not something you are worrying about.


Rust isn't really showing the kind of adoption rate required for long-term success (at least not that exhibited in the past by almost all languages that have achieved long-term success), either. Early adopters tend to be fickle, it seems.


Large companies like Meta, Google, etc have Rust as part of their official stack. The market cap of companies that have Rust listed is pretty significant compared to Elixir.


Significant compared to Elixir, alarmingly low compared to languages that truly made it. By the way, the moment when large companies start adopting a language is critical. For a language to make it, it must spread like wildfire inside those companies; if it doesn't, that's a huge negative signal to more cautious observers.


Not really, Rust can be 1% of the codebase but by Rusts nature it is implemented the most critical paths.

Rust is insanely awesome for embedding. So you can have Python app that 90% of your team works on and embed Rust for the critical parts to optimize.

But I get your point, however Rust is one of the most discussed programming languages in the past year on HN so it must be doing something right.


> however Rust is one of the most discussed programming languages in the past year on HN so it must be doing something right.

That's true. It may even be more discussed here than Haskell was five years ago (though not nearly as hyped as Ruby was 15 years ago). Whether or not that's a good sign is up to interpretation, given that HN doesn't have a good record when it comes to market success and HN hype correlation. That's not surprising given that HN is more Vogue/GQ and less NY Times, i.e. it's less focused on what's happening and more on escapist wishes.


Not really.

Rust is significantly more discussed than Haskell ever was. Haskell barely ever had more than a couple hundred comments / posts. Rust has thousands.

Haskell was never discussed more than Ruby or Python and you can go to the archives to prove it. This year, Rust is more popular than Ruby and Python combined for discussions on Hackernews.


It is also more discussed than TypeScript and maybe about as much as Go was at a similar age if not more, both of which have had a much more positive trajectory. My point is that HN hype is a really bad predictor of success or failure.


In addition to what others have said...

There are enough other acceptable languages+frameworks, and two of them (Python and JavaScript) are unfortunately just too visible and in the way.

Students, junior developers, and developers from non-CS backgrounds start with what's "easy" and available and talked about (lots of published examples, guides, etc.)

Elixir is for those who have experienced other langauges and seek something better. And since it definitely requires a paradigm shift in thinking (OOP->Functional), that puts it essentially behind a fence for many people. Why climb over the fence if Python is "good enough".

Elixir also has a great story with BEAM and all the amazing capabilities it offers, but those are capabilities that would be desired and exercised by experienced developers.

Ultimately it's a matter of mindshare. Search for programming examples for just about any topic, and you're going to get a flood of Python or JavaScript results. Maybe Java too. This is especially true since some of the programmer-mills appear to require students to regularly post blogs with trivial or lightweight essays and examples in the aforementioned languages.

The people who use real power tools are usually busy doing real things, so they generate less web fluff about their tools.


The "search for something better" is what drew me to Elixir and Phoenix. I started learning it in my spare time a few months ago. I've been doing web development, in some form, since the 90's (starting with Perl CGI scripts.) I've grown totally tired of the traditional approaches to web app development, especially over the past 10 years as JS frameworks took over, and wanted something different. The runtime (BEAM, Erlang, actors/message passing, distribution/clustering) is obviously a strong plus. Anything that gets Javascript out of the way is preferable.


What you'll find though is that FE teams don't care what you're running the api through. And they won't know how to capitalise on the BEAM. They will send you larger and larger requests, and as nice as BEAM works, the bottle neck will aways be the database.

I've seen 8 years of Elixir, and still get asked to return the world when FE wants data. No they won't ask for bits.. They want the user info and the company info for the user, and the client list for the user, and the company details from the client list for the user.. and they want it all in one response. BEAM becomes a useful tool you'll never reach for.


I hear ya. I'm mainly looking at it for smaller projects (micro-SaaS, 2-to-3 people sorta stuff), not anything with a large team.


Since I’m coming from the FE side - that’s exactly what is bothering me. I feel like Remix is a good step into the right direction, baking a backend-ish part of the stack into the FE. And crossing the networking gap in an elegant way. I see the same in Phoenix. Well, I guess I’ll fiddle with it for a bit and see if I can even handle the stack at all.


I'd argue that one of the strongest points of Elixir is that it makes really hard for juniors to shoot themselves in the foot, as well as being very simple to understand (very "imperative" overall)


These things take time. Do you expect such a new language to be adopted by 90% of developers?

Elixir 1.0 was released 9 years ago. Most people use C, Python, Java which have been around for 30+ years. I use Elixir full time but I know I'm on the bleeding edge compared to the vast majority of developers, let alone corporations which operate and change over longer timescales, and Elixir is a major paradigm shift compared to pretty much any other language. A C shop might plan to move to Rust, but Elixir is a completely another universe.

A much more interesting question is why didn't Erlang get much of a foothold in the industry. The fact that you are asking this question today means that Elixir has been instrumental in putting Erlang/OTP in the conversation, so its usage might finally start to grow thanks to a simpler syntax, healthier ecosystem and, most importantly, a lot of commercial interest.


With few exceptions, languages reach the ballpark of their all-time high relatively quickly, i.e. it is rare that a language doubles its market share (assuming it's not in the vicinity of zero) after its first decade and rarer still that it doubles it after 15 years (I think Python is the only exception to that). In other words, if you're not at 5% market share by age 10, chances are low you'll ever reach 10%.

I think it's common to see a mismatch between enthusiasm and market success in programming languages because programmer tastes vary widely, and are also not evenly distributed. Sometimes certain groups who are most enthusiastic about certain technical features of a language (and I would say those who are most enthusiastic about programming languages in general) find it hard to accept that their preferences are only shared by a minority.

Adding to the confusion is the fact that there is a numerically large (but proportionately very small) group of programming language enthusiasts that give some languages a big early boost, raising hopes, but then that pool is exhausted. So getting to 1% and generating hype is not as hard as showing stable and growth and getting a large community that sticks with you for over a decade.


IMHO there is a substantial distinction to be made, when running statistics, between languages that are effectively corporation-sponsored (Java, C#, JS, etc) and opensource "community" languages (Perl, Python, C, etc).

The former tend to peak early, powered by marketing departments, and then slowly tail off; the latter tend to do the opposite, because word-of-mouth is slow; community-powered peaks are often determined more by the appearance of a successful product based on it (Rails, Elixir, etc) than time from creation.


Except C and Perl peaked relatively early, too, and so did PHP. Yes, Ruby was late but its super-popularity was short-lived. Python is really the only example I can think of, and even Python had a healthy usage relatively early.


> it is rare that a language doubles its market share (assuming it's not in the vicinity of zero) after its first decade

JavaScript, Python, and Ruby are all counter-examples. Erlang and Haskell might as well.

I don't think time plays such an important factor. A language may exist for 20 years and then a large corporation or an all encompassing framework draws attention to it, leading to unforeseen growth.

> In other words, if you're not at 5% market share by age 10, chances are low you'll ever reach 10%.

This won't happen for 99% of programming languages and it shouldn't be a goal or even a comparison point. For example, on GitHub language stats [1], only three languages have more than 10% activity, only 7 within 5% activity. Pick other rankings, market share related or not, and you will find similar numbers. Tiobe lists SQL, Go, and PHP all below 2% and I don't think anyone could argue they failed at market success.

> So getting to 1% and generating hype is not as hard as showing stable and growth and getting a large community that sticks with you for over a decade.

Given all of the above, I strongly disagree. Getting to 1% is incredibly hard.

[1]: https://madnight.github.io/githut/


> JavaScript, Python, and Ruby are all counter-examples. Erlang and Haskell might as well.

I would say that only Python is a counterexample, and possibly Ruby although its super-success wasn't long-lasting. Erlang and Haskell have been hovering at under 1% for several decades.

> For example, on GitHub language stats [1], only three languages have more than 10%

I meant 10% as a symbol. Languages very rarely double their market share after a decade (unless they're hovering around zero, in which case they're in the noise anyway), and almost never after 15 years.

Actual market shares numbers are probably best captured here: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...


> Erlang and Haskell have been hovering at under 1% for several decades.

I am well aware that I am nitpicking at this point, but putting a restriction on your metric that rules out 99% of programming languages makes the comparison quite limiting. :D

You are ultimately only speaking about languages that are already quite popular, because even languages like Kotlin, Dart, and Swift (all endorsed by billion dollar companies) are hovering around zero by the metric you provided, and I would have a hard time classifying them as a noise. And languages like Go and SQL are still well below the 5%-10% reference point.


Obviously 99% of languages never make it at all, but Rust's adoption rate is worse than what the languages at the Go/Kotlin level -- i.e. those languages that aren't superstars but have achieved very respectable success -- had at that age. More importantly, most languages reached their ultimate "tier" by age 10 and virtually all (I think all but Python) have reached it by age 15. As of right now, its adoption doesn't suggest Rust is poised to replace C++, let alone do better. But yes, I agree that its prospects are looking better than Haskell's or Erlang's.

And again, the 5%/10% numbers were symbolic. 10% was meant to represent Go/Kotlin levels of success.


Oh wow. I did not expect this question to gather THAT much feedback, but I absolutely did not expect you showing up in the comments. Thanks for your work – it brought me to appreciate the functional programming viewpoint even with a first few steps into the language. It is a way different viewpoint compared to what I see in my daily work and will surely influence how I code in the future :)


Hi HerrBertling! I am glad you are enjoying Elixir and learning new things, I appreciate the nice words and the opportunity to be a positive influence. :)


5% market share for a programming language is still staggeringly large. It's probably okay to aim for less, and to still have a very healthy and broad technical community.


Anecdotally, I think Elixir/Erlang are too difficult/esoteric compared to other languages. That makes it hard to come back to after not touching it for a while, which means it'll be incompatible with a lot of devs that use other languages. When I come back to Golang, I can pick it up almost immediately, so I often use it for personal projects. It also has great concurrency primitives, which is one of Elixir's biggest selling points.

Where does that leave Elixir then? It's too difficult to come back to easily, plus it's too different from other languages, and it _feels_ like it doesn't necessarily do anything better than Golang, even if it does (I know it does). This makes it hard to justify the cognitive overhead.

I also think Elixir is really refreshing as long as you stay within the bounds of what you can easily look up online. Once you step out of what’s readily available it becomes _immensely_ more difficult relative to other languages. Last I used it I was also frustrated with the amount of times I had to drop into some Erlang bits to use a library, and the Erlang things it keeps were also hard to wrap my head around (why are GenServers named Genservers? Name it literally anything else)

For all of those reasons I just haven't been able to go back to Elixir. Its model of programming is just too esoteric and different for me to be able to integrate it into my stack.


Mind sharing a specific example of what made it difficult to come back to? Was it control flow, a specific library like Ecto, no types, etc?


There were several things:

* The entire model of state with Genservers

* Pattern matching made my code unreadable

* Libraries that I needed had Erlang documentation

I created some pretty gnarly code when pattern matching authorization cookies for some Plug middleware I made. Plus I had to dive into some Cowboy stuff, which had really awful documentation at the time.

"Just use Phoenix!" is what most people will say. But I simply don't want to use a big framework for a straightforward server.

Again, I realize that Elixir is probably really good at what I need it for. For instance, my latest project is a collection of Go binaries that all run at once and process data back and forth. This can likely modeled as processes under a supervision tree in Elixir as multiple Genservers... but Jesus. That's so much harder for me to think about.

What if I want to scale a specific worker up/down? With a Golang binary I can just... launch more containers with the binary. Elixir on the other hand has its own orchestrator of sorts with BEAM. So what do I do here? I guess I need to launch more Elixir servers with my code and then configure something so that it launches more processes of a certain kind within my fleet, but I have 0 effing clue how.

Edit: going through the docs, I just remembered another thing: most of the things I design are dependent on a store of some kind, whether its Redis or Postgres, or any other store. That can be confusing when the Elixir docs have a focus on its own state solutions, like GenServer or ETS.


About your pain points

* The entire model of state with Genservers

Yes and no. They are very useful. Too bad that they insisted following Erlang with that handle this / handle that nonsense (sorry if it sounds snarky) instead of building a better abstraction for the usual scenarios of creating a de facto object and calling methods to mutate its state.

* Pattern matching made my code unreadable

Pattern matching actually made my code much mode readable. I had a large web app with less ifs than the fingers of my hands. I wish I had that kind of pattern matching on function definitions when I code in Ruby and Python for my current customers.

* Libraries that I needed had Erlang documentation

This is true. The point is that many Erlang libraries had no Elixir version. Maybe the new languages on the JVM had the same problem with Java jars. Luckily translating from Erlang to Elixir is almost a 1:1 syntactical matter so it's usually easy to understand what a library does.

Edit:

> What if I want to scale a specific worker up/down?

Running BEAM inside docker was getting popular the last time I developed in Elixir with Phoenix. The project I was working on was considering to run the app in a Kubernetes cluster. We already had workers running in a docker container but I can't remember how we were spinning them up. Some service on Google Cloud.


Agree with Go sentiment. Not only that, it is a great general purpose language that does great with any heavier computational load stuff too.

I do everything with Go and Node+TS. All API services, real time / notifications, and crunchy stuff happens with Go. Node+TS handles anything else for either 3rd party things (usually the node sdk is far superior in terms of documentation and support) or one off scripts.

I've tried phoenix. End of the day I don't want to work with something which is built on something else which I don't know/understand to an even bigger degree. And fwiw, I don't see the point of deep diving into erlang/beam when Go basically does everything plus more, within its boundaries. Reminds me of JVM, you can code all day in Scala (like any junior engineer) but at some point either when shit hits the fan or incompatibility strikes, you need to learn Java and JVM internals.


For a technology to become widely used it usually needs one or more of these factors when it is released:

1. A big company that adopted it in a major way or created it (Go, Java, React).

2. A very low barrier to entry (Go, node.js, Python).

3. A major leap in productivity compared to alternatives (Ruby+Rails, Python).


I'd argue that, once you've learned how to use them, Elixir/Phoenix absolutely provide #3


And that's the big barrier.

Rails/python are immediately productive and you need minimal knowledge to start reaping benefits.

Of course once you start doing complex things you need to obtain that knowledge but it can be a gradual process


Great breakdown. I hadn't really thought of each of these in this manner


I would add

4. A critical mass of community packages and open source ecosystem so you don't re-invent the wheel for non core things (eg. Javascript, Python, Rails)


Node.js is all of these, which is why it's one of the most popular stacks.


these days you also need a half decent ecosystem around it if you want to get past the early adopter hype peak


We have switched to Elixir and Phoenix as our go to stack gradually over the last 5 years. We've found that LiveView in particular, with it's ability to avoid a separate front-end framework altogether, has let us deliver applications to clients in a significantly more productive way. We were a rails shop back in the day, and were able to build things very quickly. When the whole front-end framework thing got big, it slowed us down a lot because we were building two applications, essentially. Now that we are able to go fast again we (and our clients) are enjoying things a lot more.

I should also say that if you do need to use a separate front-end for whatever reason, I've built a thing called LiveState: https://github.com/launchscout/live_state that lets you keep things far simpler and gives a "LiveView like" experience.


I've been experimenting with Elixir lately. Phoenix LiveView, in particular, is a fantastic technology.

I can think of a few reasons why this stack might not be more popular:

1. Many of Elixir's historic strength's involve applications similar to Discord, where you have complex webs of near real-time communication between users implemented by a distributed back end. But very few apps actually need this.

2. LiveView offers a second compelling use case: single-page apps (SPA) that don't need to worry about client/server data sync. It's a surprisingly great environment to throw together a SPA very quickly. But LiveView is really new, and the first book on it is still in "beta."

3. Elixir is basically a purely functional infix Lisp2 with pattern matching and Erlang-style parallelism. With a half-baked type system via Dialyzer. It's a delightful language, but this sort of combo is a bit niche. Where I live, I can find Rust programmers more easily than Elixir programmers, for example.

4. Actually getting a dev environment installed and working currently requires reading bug trackers. The VS Code plugin, for example, currently goes into a crash loop if your shell is anything but bash or zsh, IIRC. One you get the tooling working, I'd say most of it compares very favorably to npm or Python. Elixir is trying to have an amazing ecosystem, but there are still rough edges.

The sweet spot here would be something like, "We have just a couple of senior programmers, and we want to develop a SPA really quickly, with no frontend/backend split, and faster iteration speed than more people's React stacks." And it's a bonus if your app can actually exploit Erlang's message passing or distributed programming features.

Something where you needed to keep many different user's SPA pages in near-instant sync? It would rock.


Thanks for the great reply, really appreciate it. I found the basic setup to be quite straightforward – using zsh which seems like a lucky choice now :D

I'm currently working on a backoffice software. You can do that with literally any language/framework. But as you mentioned, adding near-instant sync for different users would simply be a breeze compared to any backend with a React-ish frontend from what I saw so far. And I can totally see affordances for such a type of software going into this direction.


I made a fair amount of money with Phoenix and Elixir and I like them.

My take is that what's hindering their further expansion to mainstream are: Elixir is not curly braced and it's not object oriented. Those two alone make a big difference in familiarity. The vast majority of developers are using curly braced OO languages and it takes less effort to learn another one. I was coming mostly from Ruby and Elixir was designed with a syntax and module names similar to Ruby's.

That GenServers are objects with methods and an internal state is another, possibly ironical, matter.


> I made a fair amount of money with Phoenix and Elixir and I like them.

As a consultant, startup founder, employee?


Consultant.


how do you find your customers? do they use elixir already and need help, or are you doing new projects where you are able to choose/propose elixir to implement it?


That was a startup that decided to use Elixir and Phoenix when starting from scratch. There were not many people working with Elixir back then and they found me.

Usually my customers are already established companies, small sized, and they find me by word of mouth. Or, I have a lull between projects and I get in touch with companies I worked for in the past or that know me, and I find one that needs help. It's usually either Rails or Django.


Ironical how, this is a core tenant of erlang allowing for supervised processes with state.


biggest pro: elixir is built on erlang. Erlang was made to have incredible multithread performance distributing messages on computers from decades ago.

All those scaling problems Mastodon admins complain about? 99% of wouldn't exist if they were using one of the Phoenix based fediverse apps instead of the Rails based one (mastodon). Sure, some of the larger instances would still have issues but most folks would get plenty of throughput on one average machine.

Erlang's a great language. Once you wrap your head around the fact that = is a "match" operator and not an assignment operator... ;)

My day job is as a back-end rails dev, but I was introduced to Phoenix by a couple of the most prominent folks in that community. It is my belief that Elixir and Phoenix are unquestionably a better choice than Rails for new work. The only reasons to use Rails instead are that ruby has a bigger ecosystem of libraries, and none of your staff knows Elixir. Alternately that you're a ruby dev who's just whipping out something quick and performance doesn't, and won't, matter.


Pros:

1. Clear and readable code. Emphasis on pure data being passed around.

2. More minimalist. JavaScript stacks like T3 app (Next.js, TypeScript, tRPC, Prisma) feel like they're solving endless problems caused by other "solutions" in the stack. With Phoenix, you mostly write Elixir, some Ecto macros, sometimes JavaScript for edge cases.

3. Phoenix LiveView is amazingly intuitive

4. Way faster to prototype in, more time in "flow"

Cons:

1. Fewer UI components to pull from if you want to do something complex with the frontend

2. Not a big fan of Ecto macros

3. Have to figure things out yourself (usually read from docs or source code). Difficult for newcomers because of the lack of guides, but good for experienced devs


> 3. Have to figure things out yourself (usually read from docs or source code)

If you're all alone, there are still tons of guides, books, blog posts, et al. Documentation is a first class citizen in Elixir, and theresIf you're on a good team, they'll get you resources. If you're on a bad team? {shrug}


> JavaScript stacks like T3 app (Next.js, TypeScript, tRPC, Prisma) feel like they're solving endless problems caused by other "solutions" in the stack.

I don't agree at all... tRPC/Prisma have been a joy to work with. We still use a traditional SPA app.


The trend right now is AI, which is mostly written in Python. Most people want to write their whole stack in 1 language, whenever possible. So people just default to Python servers and React clients.

There is tooling like Carton being developed to work around this, but the gravity is always towards monolanguage stacks. In the past the incumbent would get stiff and lose resiliency, like Java or C. That's when a shiny new language like Python would come along. But with Python's governance and community it seems performance issues (Mojo) and developer experience (PEPs) are still improving. Python seems to still have sticking power.


> Most people want to write their whole stack in 1 language, whenever possible. So people just default to Python servers and React clients.

Haven't you just contradicted yourself there? That's two different languages and two different stacks.

Ironically if you were using Elixir the default would be to use Liveview so you'd use a single language.


> That's when a shiny new language like Python would come along

Python is one of the oldest languages that is still in active use, predating Java.


Python's simplicity and flexibility is what has allowed the language to reinvent itself for every new period of computing, while the paradigm- or bare-metal-bound languages have become relics. A good programming language is self-organizing. It takes on the features that are needed by the programmers of the day.


Single data point:

I spent a few hours following a couple of different (Phoenix) "getting started" guides earlier this year. Nether of them "got me started", but instead into a semi-installed broken state unable to progress without delving into other docs/stackoverflow/etc.

I am no longer in my twenties, I have no patience with that, I take it as a sign that the tech is still for enthusiasts only and I should take another look in a couple more years.

If I was being paid to learn it, I'd persevere, but I was simply curious so I'll wait for others to smooth off the rough edges.


Curious what you got stuck on


I feel it's because the main draw of Erlang/Elixir and the BEAM, was scalability. Since the time Elixir was introduced, the Cloud system vendors have developed many solid alternative answers to the scalability question, with products that don't even require developers to learn a new language.

The soft-realtime and failover concepts that Erlang/Elixir champions are still features that are unmatched elsewhere though. I have less experience with Phoenix, but writing a WebSocket server in Elixir with Erlang's Cowboy feels like the best possible way to write a WebSocket server. In fact, in that context (which is admittedly narrow), I think Elixir might be the best possible tool available for WebSocket server programming. Even if it's only used on a single machine.

I also see the Elixir team making efforts to push into the ML space. If they can develop a user friendly solution to Distributed Model Training, based on OTP semantics, I can imagine Elixir pulling some attention away from Python.

But tbf, to get the most out of the Elixir, you need to learn a little about OTP, which is very different. In fact, while I won't go as far to say learning Erlang is a prerequisite to learning Elixir, it helps alot, and that can be intimidating.

And if you're doing webdev work, then Elixir would mean that you also have to manage / maintain your own servers too. Then there's the niche status of all BEAM languages, but that's the 'network effect' I guess.


The sad answer is that it's because it's not familiar to most programmers. The quality of the tools sadly has barely any bearing on their adoption.

It's just too different and too advanced for the average programmer to use. There is no surprise that we have languages like Go now - explicitly familiar, explicitly dumb.

Elixir does not have familiar C-like syntax or the usual OO-ish programming model, and its (btw fantastic) approach to concurrency is also very strange to people coming from popular languages.


I agree with others that the Getting Started material isn’t great and documentation in general is a struggle sometimes. It’s also a “chicken and egg” problem: the smaller size of the community means sometimes community packages are not available or appear abandoned, which in turn scares off adopters.

Stepping back from all that though, what I will say is that Phoenix itself, LiveView, Erlang concepts like GenServer, the community’s willingness to help, and the language itself - all FANTASTIC.


Oh, and as far as the "shortage of Elixir developers". Unfortunately with layoffs in the startup community it's probably easy to hire just now. Even when that was not the case, we've had great success with brand new apprentices picking up the language and being productive very quickly. We recently had an apprentice go from brand-new to keynoting Elixirconf in two years. She is super amazing, but still, other apprentices have also done very well.


I’ve definitely seen that talk - Katelynn, right? :D


I was a strong Elixir shill for years. I still use it in personal projects (it's very fun) but commercially it never replaced Ruby for me. Here's my quick take:

1) There wasn't large enough gap from typical business perspective that needed to be filled by Elixir.

2) No really big company marketed Elixir. People start shoving microservices/Kubernetes/whatever new tech into any simplest app because Facebook does it. Had it been different, I believe Elixir would explode in popularity.

People here mention that Elixir means higher pay for devs but it was never the case for me. For every Phoenix role there were 5 better paid RoR/Fullstack ones. If I've proven empirically that I can provide value with RoR, why switch? I can derive joy from it by using it on my own project, and from the fact that it's much more fun using any lang on hobby projects than commercial ones.


Honestly, after years of writing python I have now gotten to a point where I fear dynamic typing.

The fact that Erlang and Elixir do not have static typing, outside of a voluntary type checker, makes me worry about using them. And yes, the approach to error handling in Erlang and Elixir is "let it crash" etc. The runtime debugging tools are excellent. There's approaches to design which ensure that even if there's some serious bug, you can still recover with minimal service loss except when your bug is something which automated testing should have caught but at this point I just feel: "Why deal with all that if you can have high quality static typing prevent you from having to deal with that in the first place?"


This is a concern that I hear a lot and it really doesn't impact Elixir projects. You're getting the same thing in different ways thanks to pattern matching.

The defacto pattern matching approach for everything gives every function an interface and you still get strong typing for all of your core types too (numbers, strings, bytes, etc).

You just don't have static typing, but the typing that's there is significantly stronger than dynamic languages and IMO it has the perfect blend of wins from static typing without the flexibility impairments that come with it.


IMO, lack of support from strong typing leaves you with nothing but writing better code in general. Undoubtedly type checker prevents obviously/not that obviously invalid code, but if you can't catch it yourself, you're fucked :)

Although most elixir code I've worked with was written by guys coming from ruby/java, and they just couldn't resist abusing macros for emulating inheritance, or overusing macros per se, once you switch your mind and clean that shit up, elixir is more maintainable than golang, for example (working for go company now). It has more tools to manage complexity and boilerplate, while nearly all golang code is complex/boilerplate itself.


dynamic typing allows for hot code swaps. which is super important for systems that need 24/7 uptime.


I worked with a team that was convinced of the superiority of elixir/erlang over ruby/rails in our ecosystem. It can accept thousands of simultaneous connections, etc. But the devil is in the details. If those connections include queries to a database then it's just a slow and clunky as every other front end framework and the learning curve is pretty damn steep. So overall the lack of integration with existing tooling and communities is what drove us away. Sure, you can do magnificent things if you keep every little bit in process but it's really hard to do that. And you need a super big box to make sure that everything is in one process.


Elixir is like a magic potion for network-bound applications, but most people aren't working on network-bound problems. It still has the elegance and consistency when you're writing a regular application. You just have to know the basics of functional programming to grok the program flow.


The combination of elixir and postgres served us well for years. I describe it as an extremely boring stack (in the most loving of ways) – no drama.

But it's just like any other framework in that, if you want to write bad code, it won't stop you.


I think the learning curve is one of the biggest challenges. Functional programming is very different for someone who got started with JS/Python/PHP/Java/C#/Ruby/etc. and you have to re-think how you do things.

And when you get a bit further in, since there’s no classes and inheritance in Elixir, you have to get into macros or other really complicated patterns if you want to avoid code duplication.

So while I love the language, it is a challenge that I you can’t use the patterns you’re used to from other languages, but have to learn new (arguably better) ways to do things. And not everyone wants to be challenged this way.


Adoption of new programming languages is always an uphill struggle. The majority of companies will exercise a lot of caution around their technology stack because they are anticipating (rightly or wrongly) difficulties hiring staff who can work with the programming language.

I think this causes a big push towards adoption of a already popular tools, until those popular tools cause significant issues. There's a weird kind of loop there where "it's not used much" is the reason something isn't used much but those cycles can be pretty tough to break.


> Why isn't Phoenix/Elixir more mainstream?

Very simply. It hasn't been adopted by a giant tech corporation as one of its main languages. All the startups that do use it aren't the size of Google or Microsoft.

Thats not to say it's not a wonderful language.

The frameworks and libs are top notch.

Elixir developers tend to be polyglots and very good engineers.

I know of plenty of small companies who did start off with elixir because they could do so much with a single language across multiple domains, with fewer engineers and lower server costs.

Maybe one of them will be the "next big thing."


It's not really filling a void.

Rails and Python have a answer to the same issue, and more libraries available to them.

Also. (and I spend 90% of my time as a paid elixir dev). It's an ugly language that makes you roll your own on so much. Migrations require you change the schemas, and you have schema modules and access modules.

The elixir docs are a mess of assumptions and there's no consistency. The number of times I have to Enum.into(%{}) after doing something with a map. Oh.. And Enum.map returns a list which is not an array but is represented in the language as an array..

Also.. With many JS libs don't embrace the many small calls to get data, so the OTP/threading side of elixir (Which is awesome) is almost never called on. Bigger calls are favoured, and elixir isn't great at this (or well no better than rails)

On the whole, I'd say the benefits of using elixir are never realised, but the cost of using elixir is paid regardless.


> Enum.map returns a list which is not an array but is represented in the language as an array

What do you mean by this?


Elixir lists are linked lists, not arrays. Syntactically, however, they do "look like" arrays. I imagine someone coming from another language is going to be confused by this...


i don't find all-in-one frameworks attractive at all.

the frontend/backend split is the easiest way to separate concerns, and ever since the first frontend frameworks i never wanted to go back to the old way of having them integrated.

the pros of keeping them separate are that i can often reuse the backend for multiple applications/websites, or replace the frontend while keeping the backend, and inversely, i can replace the backend if needed without changing the frontend, and therefore without affecting the user experience. i find this flexibility invaluable.

i also prefer to write frontend code in native javascript, although that depends on how well the transpiler/framework works in helping me find errors browser errors in the original code.

using an all-in-one framework almost always means that i have to start from scatch for a new project because the reusability is much more limited.


Because there’s very little competitive advantages in programming languages (from a technical perspective)


for me its hard to justify betting on something without a compelling edge computing (eg cf workers) story in 2023. i could not even think of a case where beam would be the right fit for a webapp/webpage except maybe a static rendered status page for something that runs on beam anyways. and i say this as a diehard erlang fan who would love to have a justification to use it more. of course there are plenty of services/ systems where beam is godsend but nothing that would fit phoenix’s target.


> for me its hard to justify betting on something without a compelling edge computing (eg cf workers) story in 2023.

fly.io? https://news.ycombinator.com/item?id=28621478

> i could not even think of a case where beam would be the right fit for a webapp/webpage except maybe a static rendered status page for something that runs on beam anyways.

LiveView / the "PETAL stack" are my first choice for web applications due to productivity & developer experience. Great summary here: https://thinkingelixir.com/petal-stack-in-elixir/


fly.io is cool but no real alternative. a compelling edge computing story would include freely moving edge functions to service workers and back if they should work offline or the request patterns change and having < 10ms cold starts with full scale to zero.


I'm not super experienced with Elixir/Phoenix, but I did notice the documentation was rather disappointing when I tried to learn it, compared to Rust. I kept trying to find a tutorial for a basic web app with Phoenix, everything I could find was for an older version which wasn't compatible with/had different names and locations for the various files than the version I had. Kinda blocked me from getting more into it.


Sorry to hear this. Phoenix v1.7 changed how it structures files in disk and that broke quite some of the getting started material. However, the guides are always kept up to date, so you can give it a try: https://hexdocs.pm/phoenix/overview.html

You can also see the resources on this page listed by year: https://github.com/phoenixframework/phoenix/blob/main/guides... - the recent launched ones are most likely up to date.


I just recently picked it up and found the official guide [1] to be pretty good. I have never read the Rust docs/book though, so I can't compare it to those.

[1] https://hexdocs.pm/phoenix/overview.html


n=1 but over my 15 year career I've tried picking up elixir and found it too difficult to learn. I found the syntax hard to read and felt I had to spend 2x more time digesting a similar method than in scala/java (my background). I wish I had picked it up though, being a consultant in elixir seems lucrative and I've received multiple offers to maintain a phoenix/elixir codebase at $150/hr.


Look at other languages, they all have their culture to make stuff. Elixir is my goto, but we haven't had the vibe of building/shipping things into the world.


Too niche, like Haskell, Lisp and other functional languages it has a long learning curve and forces you down a paradigm. Languages like C#, java and Python allow multi paradigm programming OO, functional, Procedural etc.


Network effects and platform consolidation. Its not mainstream because its not mainstream.


I think a few things are happening.

First, the language paradigm pendulum seems to be swinging back towards the middle.

Second, and perhaps more impactful, Ruby on Rails is having a bit of a renaissance.


I've worked with multiple companies which have re-embraced RoR. Mostly B2B which prefer the rapid development over the fancy UI something like React might have.


I've seen a blend here. Some react mixed into the RoR. Given trubo though.. I've seen this less. Mostly where there's a bespoke FE and BE team. Then rails just wins on dev time.


No matter if the language is Great or bottom line worse if there’s no ecosystem and libraries to promote productivity is all moo, hey we hate JavaScript but before I think of wasm I would have written most of what I want in JavaScript, this is why Go was so productive that it took just 5 years since it’s creation for the software tech world to feel the impact, that’s why rust ecosystem pushing for more high level library sugaring or “one click convenient macros” and I kinda like where ocaml is going it really needs to remove the tag “Jane street programming language”


I wrote this for Erlang about 10 years ago, and it probably still holds water: https://news.ycombinator.com/item?id=7277957

However, in 2023 rather than the 2013 I wrote that in, I'd add something else. In 2005, BEAM was revolutionary. It had things nobody else had. In 2023, it's a nicely integrated collection of a bunch of features you can get almost everywhere else, plus some features that aren't actually that important anymore because there are other solutions to the problems, even if they aren't the Erlang solutions... and most of those features are now distinctly second best.

Second best performance. Second best isolation story; we have ways of isolating things, both through convention, and with things like Rust, that don't require full immutability and the serious impact on day-to-day coding it brings. Second best messaging platform; the BEAM message bus is highly language-specific, unlike SQS, Kafka, etc., and it chose 0-or-1 where 1-or-many has been over time revealed to be generally preferable as a default. OTP is nifty, but where the Erlang community believes it must be implemented to the letter, with every jot and tittle and minor bit of functionality copied to be of any use whatsoever, in most cases it turns out some internal watchdogs + some sort of systemd-like restart (or docker, or k8s, or...) gets the job done just fine; in this case Erlang is best-of-breed, but the second-best solutions offered elsewhere do the job and the price you pay to fit into that best-of-breed can itself be an impediment at times. (Not everything can be structured as a whole bunch of relatively small communicating processes... though, admittedly, quite a bit more than many programmers may expect!) Second-best type system; I understand why BEAM's types are structured like they are [1], but after a lot of experience, the static type world has figured out to have both static types and upgradability, if that's what you need. Other features, while nifty, like process restarts with new code, just turn out to be more niche than the brochure may advertise. That's a super important feature for phone switches, yes, absolutely, but it's never actually been something I need, and that despite the fact I've done "real network code" beyond just web APIs. It's not like Erlang made my deploy process go away, it just made it different, and I don't miss not having hot restarts in practice. And I could continue on for some more features, I think I made the point though.

I also suspect the BEAM stack has a very leaky bucket now. Yes, there's definitely people who pick it up and find it very impressive, but I also expect there's a lot of people who pick it up, perhaps with a bit more experience in even one of the spaces BEAM plays in, and notice that the solutions are second best and they need something it doesn't provide well, and quietly put it back down again without putting up blog posts. For instance, if you're already hooking up to a cloud message bus and using k8s or something to run a cloud of lots of small instances, you are, frankly, 80% of the way to Erlang already, in most of the ways that count, so switching to Erlang generally comes with all the disadvantages that switching to any language would entail while not bringing all that much to the table to compensate for it. Likewise, are you heavy into serverless? It may be a completely different solution, but it leaves nothing much in the problem space for Erlang. You no longer have the problems Erlang was meant to solve. (You have different problems.)

So, I'm answering the question "why isn't it more popular", not "why does it suck". That's because it doesn't "suck". It's a fine and viable solution to many problems. While I am critical of the now-second-best nature of many of its features, the integration itself is a feature that very few other platforms can compare with! While I can find every feature now in other languages and environments, I will be putting together a stack of my own somehow, which can be beneficial, but is also definitely a cost of its own too. But other than that, BEAM doesn't bring much special to the table anymore. It is very easy to put together a stack in many other languages that exceed it in one or more dimensions, and those are often the dimensions you care about a lot (performance, static type safety, language-agnostic message busses for heterogenous deployments, there are languages/runtimes now better than even BEAM at managing tens/hundreds of thousands of simultaneous connections now... any of these can easily be a determinative factor). But its bucket has a thousand little cuts in it for the water to leak out of. No one big gash by any means, but a lot of little holes.

[1]: https://news.ycombinator.com/item?id=37261154


Hi jerf! I feel this is evaluating Erlang from an angle it is not really prescribed as a solution for.

Erlang's goal was never to be your company's message bus. Or your k8s. Even hot restarts have always been advertised as an extremely specialized feature, justified only for very specific use cases. So you are right, if someone wants to use Erlang for these specific purposes, then I would ask them to triple check their decision.

> Other features, while nifty, like process restarts with new code, just turn out to be more niche than the brochure may advertise. That's a super important feature for phone switches, yes, absolutely, but it's never actually been something I need

Agree/disagree. I agree that fault-tolerance must not be an application developer concern. However, it is a huge plus to know that my web server, connection pool, ML serving, and other essential libraries are backed by supervisors instead of crashing and getting into a unknown state. And those are errors a type system won't catch anyway: "oops, your database sent a tcp packet you were not expecting, good luck!"

> the integration itself is a feature that very few other platforms can compare with! While I can find every feature now in other languages and environments, I will be putting together a stack of my own somehow, which can be beneficial, but is also definitely a cost of its own too.

Agreed and that's precisely the selling point. If you have to build an application that needs to concurrently talk to several APIs, or perform background processing, or do real-time messaging, or distribute machine learning workflows, then you can build such application using Erlang/Elixir without bringing Kafka, Redis, or much else into the equation. Replicating this elsewhere will often require stitching three or more technologies together, which become additional techs to learn, master, and maintain on every step of development, test, and production.

In any case, I still find it "incorrect" (sorry, I can't think of a better word) to judge Erlang and Elixir by the unmet potential of its _exceptional_ features. Even if you strip distribution, hot code swapping, supervisors, they are both excellent dynamic languages with concurrency capabilities that are not seen on other mainstream dynamic languages (although I am obviously biased). If you are chasing system-level performance or static-typing though, then they are obviously not a good fit.

Ultimately, I find the question of adoption is way less technical and rational than most people expect to. That's something we often hear about technology in general, and I don't think programming languages, frameworks, etc, are much of an exception. :)


Do we have a serious contender for ActiveAdmin in Elixir yet?


https://github.com/aesmail/kaffy


Thank you, that does look like a valid competitor!


There are a few factors.

Most devs are trained in OO approaches so you have to learn to think about problems from a functional perspective. While a lot of people believe that the functional approach is a huge win (myself included), asking developers to both use a different language AND think about problems differently is a leap.

Truth be told, I was blissfully ignorant of how many concurrency issues non-BEAM languages truly have until I learned Elixir. Now I can't unsee them.

While there are a lot of polyglot devs out there who are happy to utilize a different language for its strengths, there are also a lot of developers and companies who are both time and emotionally invested in their language of choice. It's not exclusive to a particular language, it happens everywhere.

One of the unfortunate things that accompany languages that are able to do more with less, is that the companies which succeed with them...need fewer developers. There are a lot of hugely successful companies using Ruby on Rails, just as an example. Even today, you will see people fight tooth and nail against using it either because: A) They want to use their stack of choice or B) They don't understand why it's a better choice for the job.

In language terms, you win developer eyeballs with 1 easily quantifiable thing...benchmarks. X is faster than Y in benchmarks, a lot of developers will want to use X.

Quantifying productivity is harder (Ruby). Quantifying advantages of concurrency, clustering, heap isolation, maintainability with very high productivity is harder (BEAM). Benchmarks are easy.

Widely adopted language selling points as a comparison for what Elixir is up against:

- Java is taught in schools, heavily adopted in enterprise, portable, fast. It's okay at everything.

- Python is taught in schools, installed by default on Linux. It's okay at everything.

- Javascript is the only language available in browsers and has a selling point of using the same language on the client and server. Widely adopted despite a huge chunk of people who hate it.

- .NET gets the entire backing of Microsoft, usage on Windows and a natural selling point with the various Windows shops out there. It's widely useful on those platforms and has an invested and certified following.

- Apple languages are similar to .NET selling points.

- Go is portable, pretty fast has a low learning curve, fast compiler (productivity win) and the closest concurrency model to the BEAM as well as backing of Google which lets execs rest easy.

I can definitely make a case for why Elixir is a better choice for most of the things you'd use these language for, except mobile apps. But even then, there is going to be an argument. People will defend their choices and you won't see much progress. And somebody will ask for a benchmark, which Elixir won't win because it's not designed to win straight line benchmarks.


Because Elixir is a language with a fundamentally different paradigm when it comes to state and concurrency, similar to how MLs like Haskell or Rust are different then just picking up and writing some JavaScript or Python. It's different, so it's not mainstream. I think that's really the thrust of it.


I tried to learn it, but to me it just looks like if a crackhead wanted to create his own version of PERL.

The code is unreadable.

Then why would I use it if I can do the same things in Go or Python with much more sane syntax.


Here is why I think it's not more mainstream

1. The really cool and differentiated aspects of elixir require specialized deployments. Cloud vendors are optimized for stateless horizontally scalable infrastructure not stateful infrastructure.

2. Elixir is a functional programming language and this means you cannot mutate variables. While I like many aspects of elixir, not being able to mutate state makes elixir unsuitable for any task that cares about performance at all. Many algorithms are memory bound and you really cannot justify using things like linked lists.


I disagree with the "require" specialized deployments – we have hosted our elixir apps for years as stateless web apps, just like any other architecture.

In fact, you can build a release that's just a zip file which also contains the full elixir/erlang runtimes, that can be deployed on a barebones server (assuming the same libc, etc). It's not "single-executable" nice like Go/Rust/.NET but it's much simpler than it used to be.

The one use case we've seen for clustering things is having our cache stay in sync. But apart from that, we really haven't seen a need to cluster our nodes.

But if we wanted to, it's beautifully and trivially easy to do things in a cluster in Elixir/Erlang.

Immutable state is definitely one of the steeper learning curves to get over.


I qualified it with the "really cool and interesting parts of elixir". While being a beautiful programming language I don't think anyone thinks elixir is cool because you can use it to build rest api servers :)

I'd be curious to hear more about how elixir makes running a cluster easier from a devops point of view. At the end of the day you probably still want to use something like kubernetes right?


I suspect getting nodes to connect across the cluster is easy in most stacks nowadays, kubernetes or not.

But the idea that you can just call Module.func(), and not care WHICH node it runs in, right out of the box, is quite nice.

I would wager though that 90% of elixir/phoenix devs just aren't doing any of that most of the time, instead just using it like a more performant Ruby on Rails, with ecto being awesome too. :)


Just losing the while loop was a big one for me. I miss it often. I know the cost of calling something recursively. It's never going to be as cheep as a while loop.


There is Enum.reduce_while that I've used a couple times.

But I don't remember using while loops all that much (for loops/iterators, yes, but not while loops) in other languages.

I think I had a tougher time with the immutable stuff than anything else. I'd love to just update a map 3 levels down by saying thing.other.stuff = "new value" sometimes, but you can't. But overall it's nice to work with immutable structures.

Instead I either do a deep merge or use put_in(map, ["thing", "other", "stuff"]) but that doesn't always work as I expect.

If other elixir devs can set the record straight, I'd appreciate it :)


Some times I miss being able to do updates in the way you described.

Have you seen Pathex? https://github.com/hissssst/pathex It may not be what you are looking for. But I think it may improve developer experience in some circumstances.

Let me know what you think.


That depends on the compiler and lang implementation. What you are saying is true for Java or imperative langs. It's not true in langs like OCaml who has ergonomics around functional programming. while loops are just as performant as recursive functions and HOF.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: