Jon is an experienced, results-driven engineer who writes great code. He is confident and experienced at managing the unexpected.
Updated Jun 27, 2022
When starting up a new development project, one of the first decisions you need to make is which tech stack to use. Sometimes the answer is obvious–such as using Python for data visualization. Other times, it’s not so clear.
I recently had a project that required making a choice between Elixir and C#. The project would have a web frontend in ReactJS with a backend API. There was also hardware involved that would need custom firmware and the ability to “talk” to the API.
C# stood out as an obvious option because it works well for creating an API and writing firmware. But Elixir has these same capabilities and was also a viable candidate. Whatever the final choice, using a single language for both the API code and the firmware was very appealing from a simplicity standpoint.
In this article, I will walk you through the pros, cons, and features of C# and Elixir so you can compare them side by side should you find yourself also needing to choose between the two.
As an object-oriented programming (OOP) language, C# is considered a general-purpose language that works well for desktop and web applications, firmware, and more. It also has built-in garbage collection, which frees up memory when a program no longer needs it.C# works well with Windows ecosystems, and there are some great integrated development environments (IDEs) that support it. But it can also be used in Linux and macOS operating systems.
One of the biggest benefits of C# is it's popularity. There is a large pool of developers with C# skills, which makes finding and hiring C# developers relatively easy compared to more obscure languages. Because it has been around for over 20 years, there are tons of resources and libraries available, along with large support communities. It’s also considered one of the easiest languages to learn, so if up-skilling is required, it can happen fairly quickly.
The age of the C# language means it’s widely known and well supported. At the same time, that legacy also means that it was created during the era of single-core computing. Support for concurrency in C# is relatively rudimentary.
The ease with which the language can be learned and the large pool of C# developers can also make it challenging to identify truly skilled candidates. Another downside comes from the fact that C# is an object-oriented programming (OOP) language instead of a functional programming language, which means it comes with the problems associated with OOPs in general. These include a lack of parallel programming support and the potential for unexpected results. C# is also one of the more verbose programming languages and it lacks built-in support for immutable data structures.
If you find that the C# pros outweigh the cons for your particular project, then you might find the following tools helpful:
Elixir was first released in 2012. It is based on Erlang, which dates back to the mid-1980s. As a newer language, Elixir’s design has taken into account many of the pitfalls found in other programming languages over the past few decades. At the same time, it benefits from the long heritage and proven robustness of Erlang. Elixir is highly stable and reliable.
For a relatively new language, its support community is robust. However, although it features a developer-friendly, highly readable syntax, it has not yet attracted as broad a pool of developers as C#. This relative scarcity can actually be an advantage: Elixir developers are likely to be highly skilled and driven to learn and innovate.
One of the most powerful aspects of Elixir is its native support for high levels of concurrency, stemming from its origins in Erlang. As a functional programming language, it also has a high fault tolerance and is great for pattern matching–especially binaries–and for building distributed systems.
The Elixir ecosystem lacks the extensive libraries available for C#. And while the Elixir community is supportive, it is also relatively small. The low supply and high skill levels of Elixir developers means you may pay more for their services relative to a typical C# developer, and you may have trouble finding more than a handful at any given time. Finally, Elixir is a functional language, not an OOP, creating a steeper learning curve for many developers when learning it for the first time.
Whether you’ve settled on Elixir for your project or are still exploring your options, you may find the following tools helpful. Looking through them can also give you a better sense of what is available when developing with Elixir.
Technology isn’t everything
The technical characteristics of a given language and how well they match up to your project goals are important considerations. But so are your personal preferences and experience (and those of your team).
When I compared these two languages, I didn’t see either one really “beating” the other. I’ve spoken with developers who absolutely love C# and see it as their “go to” language. But I also have personal experience working in Elixir for some time now and have grown quite attached to it.
The fact that C# is an OOP language while Elixir is a functional language is perhaps the most fundamental difference between the two. I’ve read many articles that argue against OOP development due to inefficiencies and bloated code. Personally, I find that functional programming is much less mysterious. When something goes in, it’s easy to predict what will come out.
However, I also spent many years working with OOP languages, including PHP and Java (from which much of C# is derived). There can be productivity benefits to the OOP model, and in some cases maintenance costs may be lower.
When making the decision as to which language to use for my project, I also took into account my own experience levels. I was already immersed in Elixir, so I knew I could work fast. Getting up to speed with C# would have taken more time.
Additionally, for this project, it made sense to develop the backend and hardware interfaces in the same language. Generally speaking, hiring experts in one language to work across multiple elements of the architecture can be easier than finding those with the right expertise in multiple languages to support a “mixed-bag” product.
I hope this overview has provided you with some helpful insights based on one developer’s experience. At GenUI, we’re always excited to learn new technologies and new approaches to innovation. Please feel free to get in touch if you’d like our perspective on getting your product to the next level.