Debunking Elixir Myths: How Switching from React and Python Helped Amplified

A wrong way sign against a blue sky
Cynthia  Gandarilla

Content Marketing Strategist

Cynthia Gandarilla

Whether you’re a startup ready to scale or an enterprise team looking to cut costs, Elixir can help. Get in touch today to learn how we can put it to work for you.

Two particularly common myths in digital product development lead organizations to ignore the benefits of Elixir for their product:

  1. Adding more hardware can solve almost any problem
  2. Each task needs its own, specific, “right” tool

Neither is accurate. But they’re common enough beliefs that they stop CEOs, CTOs, and product development leaders from considering alternatives that could dramatically improve their product and their bottom line.

Amplified CTO Chris Grainger is not one of those product leaders. He moved his AI-powered patent search platform from React to LiveView and later from Python to Nx, and now Amplified uses an entirely Elixir tech stack.

Read on to hear how the Amplified team’s experience debunks those two common myths, and how switching to Elixir has helped Grainger and his company perform better than ever.

Myth 1: More Hardware = Fewer Problems

It’s a common scenario: A startup begins to see dramatically faster user adoption, and to keep up with demand they add more and more and more servers rather than looking for ways to use existing servers more efficiently. But that also leads to skyrocketing AWS bills that cut into the bottom line.

Over the past year, the average prices of on-demand compute instances at AWS jumped by 23%. And that represents just the latest in a trend of price hikes for server costs: AWS increased average prices in 2020, 2021, and 2022.

Increasingly, spinning up a new server to meet demands isn’t a financially viable option. And Grainger saw that firsthand at Amplified before making the switch to Elixir.

“We would do some work and then save it to S3, and then do some work and then save it to S3. And each time we did that, we had to spin up a cluster. And there’s the overhead of actually spinning up the cluster, moving the data, all of these different things,” he said. “Whereas, in Elixir, we have Broadway and I was able to use concurrent data processing pipelines.”

Now Grainger can accomplish the same work that previously required spinning up multiple 20+ machine clusters with just two Elixir machines.

It’s an easy—but pernicious—trap to fall into. Especially for startups or small teams with engineering restraints, it can be tempting to simply increase the number of servers. But that’s a short-term solution that leaves you vulnerable to rapidly increasing server costs.

Elixir removes that need entirely. With its foundation in the BEAM (Erlang’s Virtual Machine), Elixir was purpose-built to handle distributed systems without huge resource demands. It relies on lightweight processes that don’t put huge demands on your servers, which means you need fewer of them to achieve the same level of quality in your digital product.

Amplified isn’t the only company to see those benefits: Pinterest slashed its server usage by 95% and saved roughly $2 million by switching from Python to Elixir. In addition to those savings its reliability and performance improved after the switch.

Bleacher Report had a similar experience. It cut down its server needs from 150 to just eight by switching to Elixir, again without taking a hit to reliability or performance.

It’s easy to fall into the trap of thinking that the only way to scale while maintaining the quality your users expect is to increase server budget. But with Elixir, that’s not the case. You get the same—or improved—reliability and performance with significantly fewer hardware demands, thanks to the fact that Elixir is purpose-built to scale easily and handle huge amounts of data.

Myth 2: You Need a Specific Tool for Each Job

Many digital product leaders also believe that the only way to develop their product is to find a “right” tool for every element of their product. In reality, this leads to bifurcated teams and silos that slow down your development process and create headaches for overhead management.

Once again, operating a multilingual product development team can, on its face, seem like a benefit: Maybe you want the UX of a React front end with access to the plethora of back-end Python libraries.

In reality, this leads to a split team. Your front-end developers can’t get exactly what they want to execute your design team’s vision, while your back-end team is frustrated by the constraints of the language they’re working in.

This was exactly the case at Amplified before switching to Elixir. The front-end team couldn’t get the data they needed or an API design that fit their needs, while the back-end team was trying to keep data organized so it could meet users’ needs. That led to friction on the team and a dramatic slowdown in feature development.

After moving to an entirely Elixir-based tech stack, that issue evaporated. Now the entire team is working together on the same, user-critical tasks, and Grainger or one of his colleagues can build a production-ready feature in a matter of hours.

“People talk about developer experience and things like that as such a soft thing. But when it becomes the foundation of the language and a driving core value of the entire language and ecosystem you see it in the design decisions everywhere,” he said. “And it has untold knock-on effects, left, right, and center.”

Moving to a monolingual tech stack, especially in a performant language like Elixir, offers benefits that far outweigh the possible upsides of choosing a perfect language for each element of your product.

By switching entirely to Elixir, Amplified’s team broke down the silos that slowed down its production timeline and creating friction among its members. And, more importantly, it did that without sacrificing any of the experience or quality its users expected.

Conclusion

Now you’ve seen how two common product development myths can slow down the advancement of a digital product, and how Elixir dispels both those misconceptions. Not only do you not need to resign yourself—or your bottom line––to huge server costs to scale, but you also don’t need to choose the “right” tool for each task.

Instead, you can rely on Elixir for efficiency which reduces your AWS bill and improves your team performance with the single language that breaks down barriers and leaves your developers capable of focusing on the work that matters most.

Newsletter

Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box