Question: App structuring in a fully functional way

[aloslider]

(Preface: I see other users and you mentioning that your library takes inspirations from many languages such as Haskell, Erlang, Clojure and its common approaches to build programs written in a functional way, but as I'm not well-experienced in that area, I'm asking about some tips or approved articles to study.)

As far as I know, Microsoft offers a way to build a program with a generic Host feature. However, I was looking for some guidelines on how to do it in a fully functional way, but unfortunately it seems it's a bit complex topic to explain, since wiki is missing an article about structuring the application.
Then I came across this discussion (#914), where you've mentioned your other echo-process library, and I started digging in that way, but ended up with overwhelming of information and doubts about whether this is I'm looking for or not.

So, my questions are:

1. Is using echo-process library considered as recommended way to build applications with language-ext in a functional way analogous to using "generic host" ones (when you need to run some background workers)?
2. Are there other simplier ways to implement such simple logic as running some endless functions, which don't require messaging to each other and not depended shared resources? (For the context: my app uses libs that give access to 3rd-party web-APIs, so they start listening for incoming messages by statring a Tasks that run in a ThreadPool)

[louthy]

There is some general advice in the Thinking Functionally part of the wiki. But it's maybe a little dated now and could do with a refresh now that the effects system is in language-ext.

1. echo-process is just one way of building an app. The benefits are that each process is an actor. Actors are single-threaded message-processors with state. Each message processed from their inbox of messages optionally updates that state. The messages and state can be persisted (in Redis). Each process can spawn child processes. This creates a supervision hierarchy.

Because each actor has its own state and it can only be interacted with via messaging (events) it has the benefit of being an encapsulated world. And because it's single threaded, it becomes very easy to reason about - no complex concurrency issues. The inbox function is effectively a fold over a stream of messages. This has lots of nice functional properties within the process, but still allows for the sticky thing of 'world state' to exist.

You certainly don't have to use echo-process, I wrote it for this, which it's still used for today. But there are other platforms that are probably more advanced now (if maybe not as functional friendly), like Orleans, Akka.NET, etc. I certainly won't be putting as much effort into it going forward as I will with language-ext, it's pretty much 'done' (barring bug fixing and maintenance).

By the way, in one of the other discussions here, I implement a simple actor system just using the Aff and Pipes capabilities of language-ext. Obviously it doesn't have persistent state or cross-app messaging, but it might well be lightweight enough to give you some insight.

2. You may want to look at the EffectsExamples sample. Not only does it show you how to launch an Aff based application from main, but it shows how to fork a long-running-process Aff. It runs a process that ticks 10 times before exiting.

The other examples in EffectsExamples might give some inspiration too.

Finally, you might want to look into the Concurrency section of the wiki. It's useful for handling global state for whatever framework you decide to plug in to.

In terms of Microsoft and what they've decided is the way to write applications this week, this library steers clear of that. Language-Ext isn't opinionated about architecture really. This closest it gets at the moment is the effects-system (Aff, Eff, and Pipes). This may well change in future, but it's likely to be in complementary/supplementary libraries. The primary thought process is that we're all about writing pure declarative functions. Pure functions can plug into any existing framework, whether it's ASP.NET or whatever.