
C# functional language extensions and Erlang-like concurrency system - networked
https://github.com/louthy/language-ext
======
didibus
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.

~~~
innocentoldguy
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.

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

~~~
nonsince
The most popular Scheme (Racket) comes with an object system, that I almost
instantly fell on when I came to it from C#. I don't think there's any
substitute to just explaining the problems with OOP.

~~~
innocentoldguy
That depends on how you think about problems, I think. I understand OOP, and
have written OOP code for two decades, using languages like Java, C#, Ruby,
C++, etc. However, OOP never felt like a natural way to think to me. The first
time I worked with a functional programming was an amazing experience, since
FP works in exactly the same way I think. I'm not knocking OOP. I think it is
great. It just doesn't fit as well with the way I puzzle through problems.
Good thing we have options, I suppose.

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

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

~~~
dualogy
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?

~~~
christophilus
I'm curious how you made that transition,and what problem domain you're in. I
predominantly write web applications. Lots of React, but some traditional MVC
apps,too. Haskell is a language I want to love, but haven't ever managed to
find it productive in my problem space.

~~~
dualogy
Haven't done it all that long, after C# I first went Go for a few years, and
spent much time with GL shaders and such too.

Haven't done such "real-world" stuff (with a proper server side, client side,
data side etc) in Haskell either --- _yet_. It's not _immediately_
productivity-inducing _at all_. I think over _the very long haul_ , prolonged
intensive exposure makes many a developer of "mainstream/web/crud/mvp/etc
extractions" a much more rigorous, precise, exacting practitioner, which will
yield a hard-to-quantify, harder-to-capitalize-on, but still very real and
more substantive/deeper/sustained "productivity boost". It also teaches one to
think of more robust patterns of abstraction and generalization which can
translate back into programming-in-other-languages.

Nothing more tangible than that to report. Also there's a _lot_ of curious-
researcher-type "playfulness" in the wider ecosystem that's _very_ tricky to
assess what this will _actually buy_ the "let's get coding" "brogrammer" (such
as I)!

One facet that makes it quite worthwhile is that the
language/compiler/ecosystem has incredibly bright people contributing not just
by devising yet another funky undecipherable combinator for saving 10 lines of
code in once-a-decade scenarios, but in fact actual hardcore pedal-to-the-
metal under-the-hood optimizations, code check/test/validation assistence
tools, keeping it all somewhat performant in server/parallel/concurrent
scenarios and so on.

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

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

~~~
hurricaneSlider
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

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

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

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

