Elixir VS C#

[Ilyes512]

So hey guys. I was wondering how you guys think of Elixir VS C# (pro’s and con’s). I personally chose to learn Elixir and Phoenix for web based applications (inc. API’S) as that is my main focus.

So I have some college’s at work where we mainly use PHP with Laravel in the backend and javascript (Angular 2) in the front-end. We also have an application written in C#.

So to summaries my college’s standpoint: “C# can do everything that Elixir can do and more, while being backed by a large tech company with more job opppertunities on the current market.”.

I am still in the very early state of learning Elixir and so I cant come up with pro’s for Elixir. BTW he is also against functional programming languages in general (as in, funcional languages cannot replace oo languages). He also made a point that with OO you can do some functional style programming while it’s not possible to do OO style programming with Elixir.

So I wanted to share this and see what you guys think. I stick with Elixir because I like it (and it is different), I will probably take up C# eventually in the future.

[mkunikow]

I don’t think so this is the same league to compare this two langauges
Elixir is dynamic, strong pure functional language vs static typed OO C# (maybe with some functional aspects). C# is more close to Java for me. C# is not even close to Scala. In Scala league is F# from Microsoft Family.

Except this Elixir runs on Erlang OTP actor model The actor model in 10 minutes. You could get the same if you run your C# code in Akka.NET

But I think I agree that you can do more in C#. Elxir/Erlang is specialized to write robust distributed/web systems. It is good to know what tool use for task

My 2 cents about OO mutable languages. It don’t like them at all. It is very hard to reason about flow when you mutate data. And is very hard to write concurrent system using for example threads when you need to secure access to common data. And even in OO they say “use composition over inheritance”

My conclusion:
You should know at least:

• one OO language
• one dynamic language
• one functional language
  The best idea is to learn every year new language

Except this one cloud platform Amazon WS/Microsoft Azure/Google Cloud Platform

About functional jobs, I think not so bad

Functional Works

[sztosz]

For me discussions if language A is better than B are like, is rice better then pasta

From my point of view, having done a lot of Python, and little less Ruby programming (having general knowledge of bunch of other languages, and feeling rather comfortable with C#) when You write OO, You most definitely will have a lot of mutable variables and keeping state across a lot of different objects. It’s very easy and tempting to write code that is not so easy to follow when read by fellow colleague. OO is very abstractive, often detached from the core problems. You often have a lot of inheritance, and methods in different classes to do simple things, and all of it is very tightly coupled. In other words, much to often the code is a mess

In Elixir (I don’t know any other functional language yet) you just transform data, and that’s almost it. For me it’s easier to follow code and data around when i read that code. Instead of this OO abstraction there are… functions. Instead of creating object and calling methods that may or may not mutate the data inside that object you simply have a chain of methods that transform data from input to output. One function will always return exactly the same output data for given input data, there are no side effects, you can be sure, that calling function with this data, won’t suddenly change something totally different in some place in code you might never ever seen

Stating that “functional languages cannot replace oo languages” is only his opinion, and i don’t think he does have any solid arguments.

Surely you will have more job opportunities with C# then Elixir, but i can bet, companies that use C# and those that use Elixir are totally different work environments.

“C# can do everything that Elixir can do and more.” Well… I say, Python can do everything that C# does, and is more expressive. C# is very verbose, and Python not only brief but also much more readable. Why not go with Python then?

In the end it’s all matter of taste and choosing right tools for right job. There is nothing wrong in learning bots C# and Elixir. What matters is to learn how to program generally, is to learn some patterns, and when to use them, is to learn how to solve problems.

PS. after reading previous answer i can add this: I probably won’t write native GUI app in Elixir, but on the other hand I won’t probably write highly distributed fault tolerant systems in C# either. Not that you can’t, but for some specialized tasks some tools are simply better then others.

[sasajuric]

IMO the most important reason for using Elixir is to take advantage of the underlying Erlang VM (BEAM). The VM gives simple tools with very strong guarantees that make it possible to build highly available systems. IMO HA is a crucial property for web servers, and many other kinds of systems that need to run continuously and perform many simultaneous tasks.

With Erlang, it’s easier to reduce an impact of individual failures (and thus keep providing most of the service with no interruption), as well as detect failures and react to them (thus making the system self heal). I’ve seen examples of both in my production systems, and I think it’s a huge win when a system is able to provide as much service as possible, and resume complete service as soon as possible.

I’m not aware of any other platform which gives guarantees as strong as Erlang. It’s certainly not CLR, nor is it JVM. Some languages and frameworks (e.g. Scala/Akka) might resemble Erlang, but they will not give same guarantees. There will always be some hidden gotcha, or an inferior implementation of an Erlang concept. It’s simply due to the fact that the underlying runtime (e.g. JVM) doesn’t provide the same guarantees. IMO, these days only languages which target BEAM (i.e. Erlang, Elixir, LFE) can get such strong guarantees.

I talked a bit about this in my interview for InfoQ, and also in the first chapter of my book (it’s free, so you don’t need to buy the book to read it ).

@Ilyes512

He also made a point that with OO you can do some functional style programming while it’s not possible to do OO style programming with Elixir.

I’d say this is in fact a weakness of OO. And I should note I’ve been doing OO since around '95, professionally since '01 (including a lot of C#), while I’ve been working with Erlang since '10. So most of my background is OO and I’ve in fact been a happy practicant of OO, until discovering Erlang.

One problem is with mutable variables: it’s easier to introduce a bug due to unexpected mutation. Just a few weeks ago I spent a few hours debugging why something in my JS code doesn’t work as expected, only to discover that I was mutating a var where I shouldn’t have. That can’t happen if data is guaranteed to be immutable.

In OO you can never be sure about that. You can try to use only immutable vars, but in a large code base it’s hard to be certain it’s always true. Moreover, even if your code is immutable, your dependencies might not be, so there are no strong guarantees.

This might seem like a trivial thing, but it is quite important in a complex code base. Knowing that something can’t change when I call a function (since data mutation is not possible) is a big gain. It makes it easier to reason about the code and gives me bigger confidence.

Finally, FP is more explicit (so less magical) than OO. You call a function, pass some inputs, and get the result. In OO, you call a method, and it’s not clear what does it do to the state of the object. You need to read the implementation to understand what has been changed. In a dynamic language it becomes even worse, since when calling some_object.some_method(...) I can’t know what’s the type of some_object. That frequently makes the reading experience harder than it should be.

So while OO can simulate FP, it’s never completely there. After spending a couple of years with FP, my impression is that it’s at least as easy (if not much easier) to manage complex codebase, so I don’t see the need for OO features anymore.

[Hoegbo]

@Ilyes512

So to summeries my college’s standpoint: “C# can do everything that Elixir can do and more, while being backed by a large tech company with more job opppertunities on the current market.”.

First sentence is the same as saying taht this spoon makes the soup tastes better. Second part is pretty much " Let me introduce you to our bloated database system"

BTW he is also against functional programming languages in general (as in, funcional languages cannot replace oo languages). He also made a point that with OO you can do some functional style programming while it’s not possible to do OO style programming with Elixir.

This person should not be teaching in my opinion. Teachers should encourage understanding not shoehorn them intio their point of view.

@mkunikow

But I think I agree that you can do more in C#.

I disagree. You might have to run a few laps on certain things. but then again that`s true the other way around

@sztosz

In the end it’s all matter of taste and choosing right tools for right job. There is nothing wrong in learning bots C# and Elixir. What matters is to learn how to program generally, is to learn some patterns, and when to use them, is to learn how to solve problems.

That last sentence is pretty much the first thing I teach. Then I present everything else as tools.

@sasajuric

So while OO can simulate FP, it’s never completely there. After spending a couple of years with FP, my impression is that it’s at least as easy (if not much easier) to manage complex codebase, so I don’t see the need for OO features anymore.

This is something I agree with come to think about it we do not use OO hardly at all anymore at work.its either procedural , or functional.

@Ilyes512

I stick with Elixir because I like it (and it is different), I will probably take up C# eventually in the future.

@Ilyes512 Good , Learn about other languages and paradigm’s as much as you can and have the time for.

[Korbin73]

There are some good points here. Its great to learn different languages. It’s like cross training that professional athletes do to make them better at their core sport. I have been doing C# fulltime for the last 14 years. MS has been constantly evolving the language which is good and bad.

Bad: C# is just a clumsy language in my opinon. Doing something as simple as copying (clone) an object is a lot of work. You will spend a tremendous amount of time chasing null reference errors and finding elegant solutions to making your code less brittle. F# has far fewer of these issues that MS is trying to fix in the C# language. The language itself is pretty inflexible. You can’t define infix operators, or do quoted expressions to generate code easily (you have to dig into the compiler api’s to do this).

Good: C# is constantly evolving. MS finally gave us a repl (yeah it took this long), and they are working on an immutable type to fix the null reference nightmare that forces you to write in a paranoid defensive way.

On the elixir side, you can evolve the language and your tooling VERY easily. This makes it much easier to be creative in how you solve problems. Due to the actor model in the way it handle errors, you don’t have to code defensively, you spend your time writing code of value. In my experience, I find that I write less bugs even though it’s a dynamic language because decoupling is easier to achieve. On top of that, the functional model of elixir makes it much easier to understand what is going on in your program. The OO nature of C# makes it very difficult to understand as your pogram grows because each method and objects requires knowledge of what else touches it due to mutable shared state. As others have said, the mutability of C# means you will be spending a lot of time hitting F10 in the debugger due to unexpected state changes. But the good news is that you will have good job security because you will be hired to fix all of the bugs that mutability causes

So to summeries my college’s standpoint: “C# can do everything that Elixir can do and more, while being backed by a large tech company with more job opppertunities on the current market.”.

I don’t agree with this if you consider what the VM is capable of. There is no way that you can get green threading, per process garbage collection in C# without rewriting the CLR. In terms of the algorithms, yes… both languages are turing complete. The elixir market will improve. And if you need validation that FP is the way the industry is moving, take a look at the features that C# is getting in 7. Nearly every feature is an FP feature, pattern matching, immutable types, tuple implentation that isn’t crappy (like the current implementation) and local functions just to name a few: C# 7 Work List of Features · Issue #2136 · dotnet/roslyn · GitHub

[JEG2]

@Ilyes512

…it’s not possible to do OO style programming with Elixir.

I don’t agree with that claim.

[Ilyes512]

First thing! Awesome responses so far Very interesting.

@Korbin73

ake a look at the features that C# is getting in 7. Nearly every feature is an FP feature, pattern matching, immutable types, tuple implentation that isn’t crappy

That is really nice. But it shows that C# is going to do more and more things from the functional paradigm. Although it will also turn into a Swiss knife with to many functionalities (bloated).

@Hoegbo

This person should not be teaching in my opinion. Teachers should encourage understanding not shoehorn them intio their point of view.

He is not teaching it was more of a debate. And also don’t forget that I just “summarized” his thought, but that I may have been incorrect at doing this.

@mkunikow

My 2 cents about OO mutable languages. It don’t like them at all. It is very hard to reason about flow when you mutate data. And is very hard to write concurrent system using for example threads when you need to secure access to common data. And even in OO they say “use composition over inheritance”

I totally agree with the mutable languages being very error prone. One of the things I dislike for example are passing variable references to object method. It can be very error prone.

@sztosz

C# is very verbose, and Python not only brief but also much more readable. Why not go with Python then?

Well, I already know his thoughts on Python (“ieuw, tab spaced code” and “performances is BAD”).

@sztosz

In the end it’s all matter of taste and choosing right tools for right job.

I totally agree.

---

I think in general we could say that Elixir’s pro’s are it’s fault tolerance it inherits from Beam and it’s immutability in combination with the better readability that comes from the function paradigm.

[Ilyes512]

I am not totally familiar with what ever happens there, but the %__MODULE__ looks very misplaced and hacky :P. I presume it’s getting the current state within the module somehow. So in deed it might be possible, but it’s way more out of place than functional coding paradigm in a OO language (I think).

[rvirding]

One thing we found very early on is that no language is good at everything. Languages, and their systems, have a specific view of the world and whether this view fits in with the type of system you are building will determine if it is the right choice. OO and concurrency view the world differently. And saying that I can program anything in my favourite language so I don’t need another one is a completely useless argument. If we follow it to its logical conclusion we should do everything in assembler. The issue is not really what I can use but what is best to use.

Another thing we have found is that many (most?) large systems have different requirements in different parts of the system in which case one language will not be best for everything. So very many larger erlang based systems will have things written in other languages. This is relatively easy to do in erlang as it is easy to interface other languages/systems. Often you will find erlang is used as a “concurrent glue” to hold things together and interface between them.

What I say about erlang here of course applies equally well to elixir.

[benwilson512]

As a minor point of clarification __MODULE__ is simply a way to grab the name of the module the code is in, that’s all. There is no such thing as module state.

[StefanHoutzager]

I have a long background in OO programming, just started learning elixir.
I think functional languages in general will “win” from oo languages. Watch this video from Simon Peyton -Jones to hear arguments https://www.youtube.com/watch?v=hlyQjK1qjw8. Furthermore I don’t believe providing languages like C# and java with functional elements will save them. I don’t believe in hybrid languages. See http://queue.acm.org/detail.cfm?id=2611829 (Erik Meijer).

[Ilyes512]

@benwilson512

There is no such thing as module state.

Well, I thought because he showed an example of “OO” with Elixir that it would somehow store state as it is a key factor of OO programming.

[gregvaughn]

Modules do not have state, but processes do. And the processes are often named for the module that manages them. That may sound like splitting hairs, but it is a truly important distinction. A process can call code from any module, and the “managing” module of a process can also have functions expected to be called from other processes – in fact that is actually what you get by following OTP recommendations.

Modules are a code organization feature. Processes are a runtime organization feature.

[rvirding]

Yes, you often write modules which contain functions that are intended to be called in different processes.

[nubunto]

OK, I really haven’t read any replies from the page but I’m going to give you some pros about Elixir.

About the “OO” part

Ask your colleague if he ever heard of Dr. Alan Kay. Kay was the computer scientist who coined the term “Object Oriented Programming”. He invented the paradigm.

The truth is, Elixir is object oriented. In the classical sense. I won’t get into it, but you can check out the rationale here (seriously, go read that article!).
Actually, is C# who can’t get it’s own object orientation shit together. That’s not C# nor Microsofts fault though.

About the “C# can do what Elixir does” part

Well, that’s not actually true. Ask him about compile time macros. Ask him if, with C#, you can do this:

defmodule MimeTypes do
  HTTPotion.start
  HTTPotion.Response[body: body] = HTTPotion.get "http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types"

  Enum.each String.split(body, %r/\n/), fn (line) ->
    unless line == "" or line =~ %r/^#/ do
      [ mimetype | _exts ] = String.split(line)

      def is_valid?(unquote(mimetype)), do: true
    end
  end

  def is_valid?(_mimetype), do: false
end

The whole article can be found here.
Seriously. Take a good look at that code, because it breathes awesomeness. That code is compile time code that goes into the SVN of freakin’ Apache, takes out all the valid mime types FROM THE SOURCE, IN COMPILE TIME, and creates functions for all of them.

I’ve never seen C# code like that.

About the part that Elixir is awesome???

No need to say anything about that. It is. Period.

About the part that Erlang is awesome

Do you know of a project written in C# by a team of 30 people who can do 2 million concurrent connections in a single server, also backed by a large tech company? Well, I do know one in Erlang: Whatsapp.
Which is the base for Elixir. I don’t think I need to say anything more.

About the part of “more job opportunities”

As people from the software area, we all know the game changes too fast. There may not be jobs now, but I’m sure there were a group of people that dismissed Rails back in 2004 saying there would be no jobs for Ruby. And here we are, aren’t we?
I missed the Rails bandwagon, but I won’t miss the Phoenix bandwagon.

Distributed programming is easy with Elixir

C# though? Hell no. In my company we kinda use C# for everything, and I must say that distributed C# is painful. With Elixir, though? Hell, give me 3 machines so I can boost my app up!

Anyways, is great to have different opinions. Elixir isn’t great for everything, and the same can be said about C#. Right tool for the job, always. I hope I could shed some light on some of the many good points of Elixir.

[cgarciae]

I code C# and Elixir in production for the same project. C# is really nice for mobile, I use it on Unity3D and Xamarin, I think C# is the nicest classic OO (excluding the new “modern” OO like Kotlin and Ceylon). I’ve also used C# on the server side. With all this I have to say that Elixir is much better on the server. The thing with C# is that:

1. Its type system is not strong or flexible enough, types aren’t inferred, your code is very verbose.
2. Functional programming is not first class by any means. Linq is nice but that doesn’t mean you get pattern matching, persistent data types, etc.

Personally, I would only use C# for what I use it: Mobile. ASP is by no means a top notch framework, they’ve been trying to make it modern, it had severe scalability constraints, vNext is looking nicer than ever specially since its open source. That said you will get farther on the server is Elixir and OTP.

[zahid]

With respect aren’t we comparing Apple to Orange. We should compare Elixir with F# and learn many things from it. Here is an equivalent code snippet in F#:

indent preformatted text by 4 spaces

open System.Net
open System
open System.IO

module Mimtype =
    let url = "http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types"

    let splitLines (s:string) = 
      List.ofSeq(s.Split([|'\n'|]))

    let unless (s:String) =
        match s with
        | str when str = String.Empty || str.StartsWith("#")  -> false
        | _ -> true

   let isValid mimetype = 
      let wc = new WebClient()
      wc.DownloadString(url) 
      |> splitLines
      |> List.filter unless
      |> List.exists (fun x -> x.StartsWith(mimetype))

(Disclaimer: I am not a F# expert. I am currently learning Elixir and amazed by the beauty of the language)

[tallakt]

There are some practical problems with C#. It is very tied to the Visual Studio IDE. While many people like it, there are also many who don’t, reasons being bloatedness, slowness and frankly, compared to tools from IntelliJ also quite lacking in features. You could develop C# without the IDE, but I have not seen anyone to pull that one off.

To make the IDE function, VS uses code generation and wizards with lots of magic. These features hide unnecessary code complexity [in the generated code], complexity that I have not yet found in Elixir (or many other languages for that sake). What I mean here is that I would rather have some simple code that I write and understand myself, rather than a large chunk of generated (possibly two-way edit-generate) that is working, but not very easy to understand.

I would also argue that as a representative of moden software development, C# is a poor choice: As an example I was not able to create a library that was stores as source files. I needed to create a DLL file in order to link the library into my ‘solution’ and then depended on the commercial product TeamCenter in order to have debugging in source code. I actually spent quite some time om this problem that would have been trivial in mort other languages (I would also say recommended). C#/VS made it difficult for no reason other that, I presume, the cultural difference that source code should be protected and not shared.

Wrt to libraries, I have found many of C#'s to be poor copies of Ruby/Pyton/Clojure stuff, but lacking in refinement, depth and inspiration.

I would also argue that I personally find the documentation for C# core libraries difficult to navigate and quite poor in general. It is a testament to Jose Valim’s great abilities that Elixir is far superior IMHO even after just a few years with a few person’s effort, compared to the resources that are available to Microsoft…

[zahid]

I totally agree. C# is just better Java in Microsoft Ecosystem.

If you absolutely have to work in .NET CLR use F#.