8 ms·

C# functional language extensions and Erlang-like concurrency system

99 points by networked 10y ago

mattferderer 10y 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#?
- bitwalker 10y 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.
  - louthy 10y 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.
- louthy 10y 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.
  - mattferderer 10y 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_otp 10y 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).
- jahewson 10y 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.
  - bitwalker 10y 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.
    - jahewson 10y ago
      Right, that's exactly what I said above. But OS threads are preemptive in exactly the same way. It is not unique to Erlang as claimed, in fact it's the norm.
      - dxhdr 10y ago
        I think you're confusing the issue; OS processes are preemptive, threads within a process are not. Preemptive threads are not the norm on Unix / Linux / Windows systems. The BEAM VM implements its own threads which allows for them to be preemptively scheduled.
Pxtl 10y ago
Why should I use this instead of Akka.net or Orleans for actors in C#?
- hurricaneSlider 10y 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 10y 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 https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md https://github.com/Hopac/Hopac/blob/master/Docs/Programming.... http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.html http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.ht... https://neoeinstein.github.io/blog/2016/04-08-hopac-getting-started-with-jobs/index.html https://neoeinstein.github.io/blog/2016/04-08-hopac-getting-...
ZeroClickOk 10y ago
Tuples will be native first class citizen on C# 7 (https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/ https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new...)
- hurricaneSlider 10y ago
  I've been using them quite heavily already. Lovely stuff. Though disappointing that record types didn't make it in.
  - dualogy 10y 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?
    - hurricaneSlider 10y ago
      Yip syntactic sugar for immutable property only class instantiation. Structs differ from classes in that they are guaranteed to be contiguously placed laid out in memory; they're also non nullable and can't be a part of the inheritance hierarchy (though they can implement interfaces, which have some perf tradeoffs).
    - rubber_duck 10y ago
      Structs are mutable value types. Record types would let you define objects with public getters only and constructor that assigns them and a fancy syntax for creating a new object based on an existing record value + new property values, I think something like Point a = b with {X = 0} this will make using immutable record types in C# much less tedious. Will also implement other stuff like value equality override, etc. I wish this was in 7.0, this is a great way to do FP in C# when you can't use F#. Proposal link : https://github.com/dotnet/roslyn/blob/features/records/docs/features/records.md https://github.com/dotnet/roslyn/blob/features/records/docs/...
didibus 10y 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 10y ago
  Tuples and some pattern matching coming this spring as well.
  - junkyarddog 10y ago
    If the pattern matching isn't exhaustive, it will greatly reduce their usefulness.
    - rjbwork 10y ago
      It's not, unfortunately. Myself and another have started on an exhaustive pattern matching library that utilizes implicit conversion operators, type inference, lambdas, and a well designed fluent interface to provide support for it in C#. Check out, https://github.com/Jagged/OneOf https://github.com/Jagged/OneOf Distributed as DiscU on NuGet.
- catnaroek 10y 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?
christophilus 10y 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.
innocentoldguy 10y 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.
louthy 10y 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.

99 points by networked 10y 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#?

bitwalker 10y 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.
- louthy 10y 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.
louthy 10y 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.
- mattferderer 10y 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_otp 10y 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).

jahewson 10y 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.
- bitwalker 10y 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.
  - jahewson 10y ago
    Right, that's exactly what I said above. But OS threads are preemptive in exactly the same way. It is not unique to Erlang as claimed, in fact it's the norm.
    - dxhdr 10y ago
      I think you're confusing the issue; OS processes are preemptive, threads within a process are not. Preemptive threads are not the norm on Unix / Linux / Windows systems. The BEAM VM implements its own threads which allows for them to be preemptively scheduled.

Pxtl 10y ago

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

hurricaneSlider 10y 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 10y 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 https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md https://github.com/Hopac/Hopac/blob/master/Docs/Programming.... http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.html http://t0yv0.blogspot.com/2014/03/concurrent-ml-and-hopac.ht... https://neoeinstein.github.io/blog/2016/04-08-hopac-getting-started-with-jobs/index.html https://neoeinstein.github.io/blog/2016/04-08-hopac-getting-...

ZeroClickOk 10y ago

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

hurricaneSlider 10y ago
I've been using them quite heavily already. Lovely stuff. Though disappointing that record types didn't make it in.
- dualogy 10y 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?
  - hurricaneSlider 10y ago
    Yip syntactic sugar for immutable property only class instantiation. Structs differ from classes in that they are guaranteed to be contiguously placed laid out in memory; they're also non nullable and can't be a part of the inheritance hierarchy (though they can implement interfaces, which have some perf tradeoffs).
  - rubber_duck 10y ago
    Structs are mutable value types. Record types would let you define objects with public getters only and constructor that assigns them and a fancy syntax for creating a new object based on an existing record value + new property values, I think something like Point a = b with {X = 0} this will make using immutable record types in C# much less tedious. Will also implement other stuff like value equality override, etc. I wish this was in 7.0, this is a great way to do FP in C# when you can't use F#. Proposal link : https://github.com/dotnet/roslyn/blob/features/records/docs/features/records.md https://github.com/dotnet/roslyn/blob/features/records/docs/...

didibus 10y 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 10y ago
Tuples and some pattern matching coming this spring as well.
- junkyarddog 10y ago
  If the pattern matching isn't exhaustive, it will greatly reduce their usefulness.
  - rjbwork 10y ago
    It's not, unfortunately. Myself and another have started on an exhaustive pattern matching library that utilizes implicit conversion operators, type inference, lambdas, and a well designed fluent interface to provide support for it in C#. Check out, https://github.com/Jagged/OneOf https://github.com/Jagged/OneOf Distributed as DiscU on NuGet.
catnaroek 10y 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?

christophilus 10y 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.

innocentoldguy 10y 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.

louthy 10y 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.