C# functional language extensions and Erlang-like concurrency system

by networked • 9 years ago

99 48 9 years ago

As someone new to Erlang, I'm curious what the main benefits of this are? It's obviously pretty popular on GitHub. To my understanding, you can use F# with C# in .NET projects. Also from what I've read, it seems like the biggest benefit of Erlang is BEAM. Would anyone be willing to explain the benefits of this? Is the main benefit just to allow more functional programming in C#?

bitwalker2• 9 years ago

As a long-time C# dev, now full-time Erlang/Elixir dev, I've written things like this before myself when attempting to bring some of the FP tools I loved back to C# for my own benefit - so this looks really familiar in that sense. This is by no means an actual competitor to Erlang's actors - for one thing it lacks any form of supervision, which is really the most important aspect of Erlang's actor model (i.e. the "let it crash" philosophy). There are other things missing as well (such as the OTP behaviours, e.g. gen_server, provided by Erlang).

That said, this looks like something I'd definitely use, or at least experiment with in C# if I was still doing work in the language - though for the actor bits I would probably lean on Orleans.

louthy7• 9 years ago

This is by no means an actual competitor to Erlang's actors - for one thing it lacks any form of supervision

Author here. That is simply not correct. It has a full supervision hierarchy as well as a compositional strategy system for creating policies that handle failures. The strategies can also be scripted as part of the config, to detach the failure handling entirely from the actor itself.

louthy7• 9 years ago

Hi Matt, I'm the author of the project. The reason I wrote it is because I have a 12 year old C# project that's creaking at the seams from the issues of OO development. I believe OO becomes cognitively very difficult when a project reaches a certain scale. Functional programming allows my brain to manage complexity much better.

I couldn't just jump ship and use F#, Haskell, or Erlang; so I decided to bring what I'd learned from those languages into C#, and create a library that will help me write better C# code.

My mission is to create a library that reduces the cognitive burden of writing C#. It isn't a functional manifesto for C#, it just looks like it because I've found that's the best way to achieve my goals.

The Process system (Erlang style actors) is there to deal with the 'edges' of functional code. It's not possible to be pure like in Haskell, and so you will have stateful code - with all the problems that come with it, i.e. shared memory, locks, mutability, etc. Actors allow a certain amount of control that you don't get from C# classes: Single-threaded and no-shared state. They can be distributed anywhere and the mechanism for interaction is the same. You can build in routing or proxying to do load-balancing, etc.

mattferderer2• 9 years ago

That makes perfect sense. Thank you for taking the time to reply.

The thought of trying to fix up an old code base did not even cross my mind. Probably because that is what my nightmares are made of.

im_down_w_otp4• 9 years ago

It's not clear to me from a cursory look through the docs how the scheduling system works. "Erlang-like" concurrency works so well predominantly because the runtime uses preemptive scheduling instead of cooperative (which is what basically everything else uses, unfortunately).

jahewson2• 9 years ago

That's incorrect, most scheduling systems, including OS threads are preemptive. Erlang's scheduler itself is actually cooperative - though it can still preempt the "processes" it schedules.

Erlang's message passing system is probably more important to the success of its concurrency model than the specifics of the scheduler. As proven perhaps by the success of Akka and other actor-based systems built on a different threading model.

bitwalker2• 9 years ago

I think what he meant is that from a programmer's point of view, Erlang appears to be preemptive (there is no explicit yielding of control, ala golang or lua, the two I can think of off the top of my head), even if the scheduler itself is cooperative. The place where this most obviously reveals itself is with NIFs, where the scheduler can no longer preempt the process, and is blocked until the NIF finishes executing. At least that's my understanding.

im_down_w_otp4• 9 years ago

I was talking about scheduling in actor-pattern frameworks and non-OS runtime environments (JVM, C++, Python, etc. etc. etc.).

Erlang's scheduler is preemptive. Erlang processes can be preempted by the scheduler in the middle of execution and moved to the back of the scheduler queue or to another scheduler thread. There is no requirement for a process itself to yield time back to the scheduler to make sure that other processes receive some execution time. This is one component of how it achieves "soft-realtime" semantics. Eight processes, on a system with 8 scheduler threads, running in a tight loop cannot cause all other processes in the Erlang VM to be blocked. Other processes will be given time.

The only thing that violates this guarantee is long-running or blocking code executing on the native side of the NIF boundary.

Akka, goroutines, Cloud Haskell, etc. are exactly the kinds of things I'm talking about when I say I don't understand the point of actor frameworks running in environments that can't preempt actor execution. You had better hope all your actor implementations are well-behaved or that the implementations you're going to import from someone else are all well behaved... otherwise you're going to lockup your scheduler's thread pool.

rdtsc• 9 years ago

That's incorrect, most scheduling systems, including OS threads are preemptive. Erlang's scheduler itself is actually cooperative

From what I know Erlang's scheduler preempts processes it executes. Can you explain what you mean by it being "cooperative". It precisely useful because it is not cooperative. And processes don't have to "yield to" the scheduler.

dxhdr2• 9 years ago

That's incorrect, most scheduling systems, including OS threads are preemptive. Erlang's scheduler itself is actually cooperative - though it can still preempt the "processes" it schedules.

OS processes are preemptive, however process threads are not. I'm not sure what you are trying to say about Erlang's scheduler itself being cooperative. It is a preemptive scheduler.

Erlang's message passing system is probably more important to the success of its concurrency model than the specifics of the scheduler.

I disagree, preemptive concurrency is a fundamental piece of BEAM's success. Preemption gives Erlang its fault tolerance and low latency guarantees. If by message passing you mean immutability, then perhaps they are of equal importance.

dozzie3• 9 years ago

Not quite, as a sibling comment states. Everything today's operating systems provide in scheduling (processes and OS-level threads) is preemptive. Erlang's (BEAM's) scheduling is cooperative, but Erlang compiler inserts yield points in appropriate places, so it actually looks and feels like preemptive scheduling.

im_down_w_otp4• 9 years ago

Erlang processes can be interrupted by the scheduler. Saying that Erlang scheduling is "cooperative" because it uses reduction counts as one (among many) hints about how to decide what to schedule is like saying that preemptive OS kernel schedulers are "cooperative" because they use mechanisms like time-slices, etc. to attempt to balance execution resources.

The Erlang VM can intercede into a running process, and also does this with some of it's BIFs implemented in C.

Matthias247• 9 years ago

I think it works similar to how Akka actors work. The actors are purely reactive and their message processing functions are called whenever a new message arrived. You shouldn't block them (e.g. to wait for a response from another actor), because that blocks the actor from doing other things as well as an OS thread. Instead you should return and wait for being called again with a response message. This makes some things a little bit harder to write, since you will need some kind of state machine and store the current state of actors in a more explicit fashion. However you can also achieve a higher reactivity with this kind approach, so it's a trade off. In C# you could basically get some kind of best-of-both-worlds by allowing async handlers (that return Task<T>), which means no thread would be blocked if the message handler would do a long running async operation. I think that was discussed for Akka.Net, but I don't know if it's now supported or not.

louthy7• 9 years ago

Author here. "Erlang-like" was mostly used for programmers that aren't aware of actor systems, or the current de facto standard language for actors. It's not a statement on its competitiveness with Erlang.

The system simply uses the TPL for scheduling (which is actually very good).

Pxtl• 9 years ago

Why should I use this instead of Akka.net or Orleans for actors in C#?

hurricaneSlider3• 9 years ago

I personally use both Akka and LanguageExt together. The higher order type features, monadic operators and types such as Optional and Either are useful for any project

ZenoArrow• 9 years ago

If you're interested in Akka.NET, you may also be interested in Hopac:

https://github.com/Hopac/Hopac

https://github.com/Hopac/Hopac/blob/master/Docs/Programming....

http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.ht...

https://neoeinstein.github.io/blog/2016/04-08-hopac-getting-...

ZeroClickOk• 9 years ago

Tuples will be native first class citizen on C# 7 (https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new...)

hurricaneSlider3• 9 years ago

I've been using them quite heavily already. Lovely stuff. Though disappointing that record types didn't make it in.

dualogy2• 9 years ago

Doing Haskell nowadays, been years since touching C# --- maybe my memory is fooling me but didn't have C# "structs" (or whatever they were called) from the very start? What else exactly are "record types" if not those?

Or do you simply mean some leaner syntactic sugar for their on-the-fly instantiation?

louthy7• 9 years ago

Author here. When I started the project C#6 was just arriving. It's awesome to see the ValueTuples coming through for C#7. I have been adding some super-powers to them for lang-ext 2.0 (which is work in progress):

Example of extensions for ValueTuple<A,B,C> (there are extensions up to ValueTuple<A,B,C,D,E,F,G> and Tuple<A,B,C,D,E,F,G>)

https://github.com/louthy/language-ext/blob/type-classes/Lan...

It allows cool stuff like this:

    var abc = ('a', 'b').Add('c');                                           // ('a', 'b', 'c')
    var abcd = ('a', 'b').Add('c').Add('d');                                 // ('a', 'b', 'c', 'd')
    var abcd5 = ('a', 'b').Add('c').Add('d').Add(5);                         // ('a', 'b', 'c', 'd', 5)

    var sumA = (1, 2, 3).Sum<TInt, int>();                                   // 6
    var sumB = (2, 4, 8).Product<TInt, int>();                               // 64
    var flag = ("one", "two", "three").Contains<TString, string>("one");     // true
    var str = ("Hello", " ", "World").Concat<TString, string>();             // "Hello World"
    var list = (List(1, 2, 3), List(4, 5, 6)).Concat<TLst<int>, Lst<int>>(); // [1,2,3,4,5,6]

didibus• 9 years ago

C# is probably my recommended language for anyone looking to get started with functional programming and event handling.

Its familiar Java/C like syntax, classic use of OOP, enterprise vibes will mean it'll be very familiar and easy for most to pick up. And as you go deeper, it'll introduce you to anonymous delegates, lambdas, true generics, higher order functions, true closures, list comprehensions, anonymous types, type inference, lazy evaluation and even a sprinkle of monads.

With the language extensions, you can get even further.

This is a great way to start learning about FP concepts without even knowing it and it'll make your switch to a more thorough FP language much easier, such as MLs, Lisps, Erlangs, and most proof languages.

codemonkey2017• 9 years ago

Tuples and some pattern matching coming this spring as well.

junkyarddog• 9 years ago

If the pattern matching isn't exhaustive, it will greatly reduce their usefulness.

catnaroek4• 9 years ago

true generics, type inference

This has absolutely nothing to do with functional programming.

delegates, lambdas, list comprehensions, anonymous types

Syntactic sugar.

higher-order functions, true closures

Java has them too. They're called “objects”.

a sprinkle of monads

Every higher-order language with strict evaluation (which includes every object-oriented language) already has at least one monad, whose use is pervasive and inescapable.

So, unless you have user-definable monads, where is the improvement?

louthy7• 9 years ago

So, unless you have user-definable monads, where is the improvement?

C# does have user-definable monads. There are many in this project (Option, Either, Try, TryOption, Task, Reader, Writer, State, Parser, ...)

innocentoldguy3• 9 years ago

I think mixed-paradigm languages make it harder to get started with functional programming, since they provide a crutch to other paradigms, which people tend to fall back on. I'd recommend Scheme, or maybe Elm (if you're doing web programming), as good starting points to learn FP, since both languages are relatively simple to learn and won't let you implement OOP, for instance.

catnaroek4• 9 years ago

Scheme will let you implement an object system on top of it, using mutable closures, and perhaps macros for syntactic sugar.

Impl0x• 9 years ago

I got started with functional programming with F#. I agree that there were times when I used its hybrid nature as a crutch, but I think there's a value in using a hybrid language if your goal is to learn. F# let me write out code in an imperative style that did what I wanted it to do, and then from there I could refine the code and take advantage of the functional features as I learned them. It's a nice way to learn which features from the different paradigms are equivalent, and it really lets you appreciate what you gain from using FP.

christophilus2• 9 years ago

Reading through the docs, this looks really nice. Forget the Erlang in the title, and just think of this as a nice functional C# hack. I'm thinking of using C# on a side-project because the tooling around F# in .NET Core on Mac is sub par right now. This library might be just the ticket.

innocentoldguy3• 9 years ago

I haven't programmed in C# for 14 years, but it is nice to see projects embracing functional programming and the actor model. It solves all kinds of concurrency headaches. I'd still opt for Erlang or Elixir over this due to OTP and BEAM, but it is still great to see things moving in this direction.

louthy7• 9 years ago

I didn't realise I'd hit the front page again! I'm the author of this project. Feel free to AMA.

I'm currently working on V2 of this project to bring ad-hoc polymorphism to C# (almost type-classes), and splitting out the Core and Process (actors) libraries to separate repos.

C# functional language extensions and Erlang-like concurrency system

Related Stories