Elixir VS C#

I’d say it a little bit different:

yep learn one functional language and you will never want to go back, but you will be forced to every now and then :rage:

They lured me with haskell in the first semestre but now? I have to use C for openGL, some of my co-students have to use some other C-like language for an embedded device. Firsties are teached in Pascal, Haskell is only shown to a handfull of students. Java for OOP. As far as I have heard situation is even worse at other universities, where different paradigms are teached using the same language…

And to be honest, I like it beeing trained to stay diverse. I’ve seen people loosing their jobs because they weren’t flexible enough…

7 Likes

Yes you are right you will never want go back :+1:

Why not to use Rust instead C?

4 Likes

Rust is a great system language! You get native speed, and no freakin’ SEGFAULTS. That ought to be at least tempting.

If you’re doing embedded and willing to go full crazy, why not nerves?

4 Likes

I can only guess, but I do think that it does depend on at least one of the following:

  • Rust is not officially taught on my university.
  • Rust would make the graphics course unnecessary complex due to life time restrictions
  • There is no LLVM code gen available for that device, only a propretiary compiler for that C-like language
  • Rust is not available in official Ubuntu 14.04 repositories
  • Rust is much newer than the current curricula (my curriculum is from 2011)
  • No sane student wants to learn a new language AND a new topic at the same time
  • Most other students at my university appear to be very monoglottish… Evangelizing the language used at their sidejob while using languages taught as less much as necessary and as less as possible…
2 Likes

I have some stuff flying around I like to do using nerves/rust. But I need to wait for some better conditions:

  • Nerves need to support the Pi3-Cam
  • Nerves and Rustler need to work together
  • Rustler needs to keep up with rustup.rs
  • I need to have much more time :slight_smile:
3 Likes

I know this is a couple months old, but I’m surprised no one mentioned “async” in this. This, for me, is the shining attribute of Elixir/Erlang. I’ve been mostly in the C# world for the past decade or so, and I’ve been writing multi-threaded code using BackgroundWorker, callbacks, and more recently async/await for a long time (in Delphi before that as well!). But in my eyes, those kinds of constructs and others, e.g. mutexes, semaphores, critical sections etc., are basically afterthoughts from the transition from single-threaded procedural paradigm to more and more multi-threaded one.

I am loving Elixir/Erlang because it doesn’t add asynchrony on top of something else…it IS asynchronous! And I am a hard-core OO dude that doesn’t hate FP stuff…I just didn’t grow up that route. But the most common issue that I’ve run into with FP is handling state. In even simple examples in most FP languages, state on a project-wide basis seems at best to be tricky to handle properly. Elixir has addressed this with Behaviors, and specifically the GenServer and Agent (which I believe is built on GenServer anyway). It’s like the best of both worlds…FP with superb, and natural state-handling capabilities. And asynchronous coding has become much more straight-forward, because it does these things (mostly) transparently - though you still need to be aware of race conditions and where the asynchrony is happening.

I’m not an Erlang expert, but I think the Beam+Actor Model architecture is the best for its asynchronous design. And Elixir (and its community) is adding to that awesomeness some really excellent options making it much more accessible to those of us from the OOP world.

2 Likes

Jet.com is hiring F# devs

1 Like

For me comparing these two languages is like to compare whole programming paradigms. C# is different than Elixir, so you can learn it as well as and use when it’s useful. Languages are tools- don’t try to solve every issue in home with hammer. Same story here- Elixir will be great to other things that C# is.

1 Like

That’s a great point. If I lived in NYC I would definitely contact them. But I am in Michigan and they won’t consider remote workers.

It’s a nice notion to be a Language Agnostic who will pick the right tool for the job but I would expect that many if not most developers don’t have the luxury of that choice (provided they cared). For example in 2007 at Google:

You have to play inside the fence defined by C++, Java, Python, and JavaScript.

i.e. anything not in that list cannot be the “right tool for the job”. And in many environments the selection of sanctioned languages/tools is even more restricted than that. For stakeholders “can I readily (and cheaply) hire developers for maintaining this” is a significant aspect for “the right tool for the job”. For Google this even became a primary consideration in the design of Go:

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

So given the existing install base of solutions already implemented in C# and given that developers familiar with C# are more readily available make it much more likely that C# will be used for something that F#, not to mention Elixir, is better suited for, not the other way around. So that gives C# has a huge advantage.

Elixir may need some help from people who also handle mainstream languages like C# in order to infiltrate the mainstream (rather than, for example, poaching the Ruby/Rails community) in order to “cross the chasm”.

For one it would be nice (and helpful) if Erlang was considered less niche and more mainstream. According to Bryan Hunter in his presentation CQRS with Erlang: “60% of the world’s mobile traffic is going through Erlang” - that should make it worth paying more attention to (but that didn’t seem to generate or require a tsunami of Erlang developers). Elixir as a “more accessible Erlang” should benefit from a wider awareness of Erlang’s maturity and capabilities.

2 Likes

Yep I agree this is Google primary stack and I don’t think so they move something beyond this.
But it doesn’t mean than any can’t contribute to other languages for their’s APIs.

It is also wise to remember that the “right tool for the job” is difficult to discern when the job itself is so often poorly defined.

2 Likes

Just keep in mind that F# is just the translation of (O)?Caml for the .NET platform :wink:

In fairness (and yes I am splitting a hair here), F# is both more and less than OCaml on the .Net platform. F# adds Active Patterns (there’s no such thing in OCaml as far as I know). F# has modules like OCaml but the focus is more on namespaces which is in keeping with other .Net languages.

And, of course OCaml isn’t tied to the CLR. While Microsoft may argue otherwise (especially these days), CLR is still pretty much de facto Windows and Windows only. Yes, I know their efforts to port to Linux–but I also know that their efforts are still pretty much at the proof of concept level for now and it’s likely to be that way for the foreseeable future.

While I quite liked Elixir/BEAM, I’ve actually gone with F#. It’s a statically typed functional language, supports lightweight processes, reasonably simple to use Actor model via orleans, there’s lots of tooling, and can leverage a large amount of libraries which allows integration with lots of things in a mostly effortless way. MS is pushing everything open source and cross platform as well.

Elixirs advantage is not really that it has BEAM / LWP / Actors etc… it’s that most everything gets built with that model in mind. Which is nice, F# doesn’t have that as it’s a smaller player in a larger ecosystem, so most things don’t explicitly take advantage of F#s capabilities/philosophy.

When it comes to actual coding… you can write in a very similar style in both, the main thing I like is the static typing in F#, which despite all the arguments for not having it in Elixir, it still helps eliminate errors.

1 Like

You may be interested to revisit .NET via F#, it has agents…

check out

https://blogs.msdn.microsoft.com/dsyme/2010/02/15/async-and-parallel-design-patterns-in-f-agents/

and there are various things talking about how to easily get genserver type functionality using F# and then on top of that there is orleans

1 Like

This is why I really want an OCaml back-end to Elixir, entirely possible, just needs to get done. :slight_smile:

For note, F# was based on OCaml, most code that works in F# works in OCaml almost unaltered (except for the accessing of .NET specific oddities). So if you like F#… :wink:

Also, can’t F#'s Agents crash everything by calling the wrong thing? That is a .NET limitation, it does not have the hard guarantees of something like the BEAM, regardless of the language or libraries used…

Two things, F# does not have modules like OCaml, that is one of the big things it is missing, it has most of the abilities, but not all, last I saw anyway. Also based on https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/active-patterns for Active Patterns, can’t you just do that with a single function call between the match and input? What does this gain other than magically coercing types (which OCaml abhors as it harms readability)?

But yes, I badly badly want some for of typed Elixir, and an OCaml backend to Elixir would be wonderful!

2 Likes

One benefit Elixir/Beam model over .Net is that each process has it own garbage collection and each process is isolated. If you want to get something similar in .Net you need to put application in containers.

I there is also Akka .Net Orleans and Akka Actors: A Comparison

Also you can use http://reactivex.io/ with .Net platform.

1 Like

Akka (and Akka.net, I’ve messed with both) are fantastically designed, I would use them in a heartbeat if I had to use the JVM (or .NET) system(s), but they still entirely lack the guarantees that the BEAM has. And yes, the per-actor GC is absolutely wonderful! Most of the time the GC is never touched, the process is spawned, does some work, then everything is freed all at once without needing to worry about expensive GC Sweeps that both the JVM and .NET absolute have to incur just due to their OOP’ishly internal design. ^.^

1 Like

First…Thanks for replying. Seriously. It’s been a long day. :sweat_smile:

Second, I quote these partial fragments specifically because my point in coming to Erlang (with Elixir as a surprising and wonderful added bonus) is that concurrency is not something “added on”. It is designed this way at its very core, with every facet oriented to it. From the GC and isolation that @mkunikow mentioned to immutability to supervisors/OTP and processes, it has evolved organically to handle nodes (whatever they may be) operating in parallel from its very inception.

And with ibGib, I needed a completely concurrent system. And unlike many here (and elsewhere in the FP world), I really :heart: OOP. I can still remember reading my first book on OOP about polymorphism, inheritance, data hiding, encapsulation and thinking “Wow, this is incredible” (I had only done some C, Basic, and assembly at the time.). Honestly I don’t get that feeling with FP alone (older now hah!). But Erlang/Elixir + OTP was exactly what I was looking for with ibgib. It was so natural to code the engine in it, and I feel blessed that I found this ecosystem (and community). But I digress…my point is that to me the BEAM isn’t about the “actor model” or FP or any other individual patterns or aspects built on top of something to be concurrent - it just is concurrent.

getting off soapbox :wink: Like I said, it’s been a long day!