I mean, what is the negative impact on that in your opinion?
I will study this, thanks a lot ^^
In Akka.NET, you can support self healing systems, so as in upcoming MCOCaml and Erlang`s BEAM.
ShalokShalom
OvermindDL1
It pollutes the language, making more forms potentially ambiguous in addition to making it more difficult to extend to something truly unique later.[quote=“ShalokShalom, post:73, topic:3693”]
In Akka.NET, you can support self healing systems, so as in upcoming MCOCaml and Erlang`s BEAM.
[/quote]
Akka and Akka.NET are just libaries, they can already be supported on the systems, or Python, or C++, or whatever languages want to implement such a similar library. The self-healing aspect has absolutely nothing to do with the language.
1
ShalokShalom
Well, I am informed that they are “just” libraries - the thing is, I can use it.
Self healing actor model is possible on F-Sharp and this is whats important.
What do you think about ZeroMQ?
And one more:
0
gon782
Akka.NET seems to suffer from the same issues you always find when not having a proper scheduler and trying to run Erlang-like systems, no? According to the docs it uses the .NET thread pool as it is and hopes it’s good enough. You can still just starve it by having long running things and then it’ll struggle to add more threads.
Having to worry about not blocking is not an acceptable solution, IMO.
1
OvermindDL1
Precisely, it has no preemptive or even cooporative scheduling that extends past Native OS Threads last I saw.
Though C++ has cooperative greenthreads that can swap on IO. ^.^
1
ShalokShalom
OvermindDL1
Similar to how it is in Erlang actually when MCOCaml lands. 
MCOCaml uses algebraic effects to basically control a given context, and thus any functions it controls it will be able to pre-empt at those call points (just like how Erlang can only pre-empt at function calls, generally only external function calls as module-internal calls often get optimized out depending on size, same in OCaml).
C++'s greenthreads (lots of libraries for it) can swap on any function they control as well, though not ‘quite’ to the same detail, but enough for the majority of cases excepting tight loops or so, however you can also have it spawn more system threads to handle the greenthreads if some start taking too much time and use work stealing to steal them off other threads.
1
ShalokShalom
OvermindDL1
OCaml’s GC is more generic sadly, though the fact it can generate significantly better code than the BEAM due to knowing the types of things means it will outperform the BEAM in most situations anyway.
1