Elixir VS C#

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

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

Strip-Passage-de-relai-foireux-650-finalenglish.jpg650×631 262 KB

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.

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 ).

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.

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.

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

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

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 Good , Learn about other languages and paradigm’s as much as you can and have the time for.

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

I don’t agree with that claim.

First thing! Awesome responses so far Very interesting.

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).

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.

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.

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

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.

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).

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.

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.