Revisiting async classes

[Night-walker]

It's not the first time I have doubts if asynchronous classes are necessary for the language in their current form. Well, that's another episode of this story.

Async classes seem like a nice idea, but for a very specific use case. The one we haven't found yet which requires high-level service-like threading model while staying simple enough for async classes to be applicable in the first place.

I mean, for trivial concurrency we don't need anything but magical !! -- excitement operator :) -- and channels with futures. For complex, large-scale tasks the ability to wrap inter-thread communications in method calls (that's what async classes are essentially about) will probably not be the most important thing to care about. Usually some broader, more comprehensive metaphor is applied in such cases, namely the actor model.

By getting rid of async classes we not just make the language simpler, -- arguably the largest single place haunted by demons of possible inter-feature conflicts disappears. A lot of potential issues regarding integration of async classes into the language evaporate immediately. I think it would make things simpler.

It may still be reasonable to reserve way to imitate async class behavior -- it could be provided by dedicated module in the standard library. Not the exact semantics -- that's hardly doable without direct syntax support -- but perhaps some building blocks to construct similar communication model.

Overall, I believe that the basis, backbone of Dao should ideally consist of simple elements backed by universal principles. Small and flexible things are easier to combine and intermix, their potential is often greater, whereas complex and specialized abstractions always require special treatment and rules. Ditching async class will leave us with much lesser amount of design problems to worry about.

[dumblob]

I think, that asynchronous classes didn't find any use up-until-dao, because we didn't have any easy way how to say "hey, here is a completely independent, asynchronous entity, which you can communicate with using it's methods" and therefore nobody used it (Erlang is by far too low level and Smalltalk-like languages are slow and too obscure for use in large scale). But over time, I'm getting more and more into thinking about designs/architectures utilizing such asynchronous classes and I'm about to incorporate them into my code in the near future. It feels like a new tiny paradigm, which is very handy (it pushes one to think high-level as you wrote and also to minimize the number of methods and number of their invocations, because they're costly).

On the other hand, I don't argue it complicates Dao, because it does.

Did you have any specific building blocks in mind (in case we wanted to "move" this functionality into a separate module)?

[Night-walker]

But over time, I'm getting more and more into thinking about designs/architectures utilizing such asynchronous classes and I'm about to incorporate them into my code in the near future.

If there are indeed numerous cases where async classes can be used, then their existence may be deemed justified. Still, note that async classes are very limited comparing to Erlang processes or any other actor model implementation. They are largely incomparable. They are simple to use, however.

Beside what I already pointed out, use of async classes produces code where inter-thread communications aren't very apparent ('cause they're hidden under method calls), which isn't good for readability...

Did you have any specific building blocks in mind (in case we wanted to "move" this functionality into a separate module)?

Not at the moment, that may require some considerations.

[dumblob]

They are simple to use, however.

This might become the reason overweighting their limitations and justifying their existence in Dao.

Beside what I already pointed out, use of async classes produces code where inter-thread communications aren't very apparent ('cause they're hidden under method calls), which isn't good for readability...

This can be (and should be) improved.

Not at the moment, that may require some considerations.

Me neither, but I'll think about it a little (I'm afraid, I'll end up with a copy of some existing actor model implementation).

[Night-walker]

They are simple to use, however.
This might become the reason overweighting their limitations and justifying their existence in Dao.

It's not enough if async classes are falling outside of major use cases.

Not at the moment, that may require some considerations.
Me neither, but I'll think about it a little (I'm afraid, I'll end up with a copy of some existing actor model implementation).

Async classes have little to do with the actor model. They usually cannot be used where actors are typically employed, hence my doubts about their utility.

Basically, the largest thing necessary to emulate async classes is the ability to create future value without creating new task. Supporting that would open way to achieve the same kind of communication without touching the syntax.

[daokoder]

Though I am a bit reluctant, I am starting to become inclined to remove async classes. The design and implementation of async classes are quite simple per se, but they might have problems to be integrated with other features (one I can see is interface, it would be necessary to disallow matching async classes to interfaces). Also its use seems not as common as I expected, so far all I need to async function calls and mt methods.

But I prefer not to remove it in hurry, let's give it more consideration, and see if there are ideal use scenarios we have overlooked.

[dumblob]

@daokoder do you think, that it would be possible to write some highly efficient Dao module providing some form of an actor model (e.g. from the point of view of high-level concurrency based on message passing modelled as an interaction between actors) in the future? Such module could also transparently support other means of message passing than memory copying/sharing, e.g. sockets/network.

[daokoder]

@daokoder do you think, that it would be possible to write some highly efficient Dao module providing some form of an actor model (e.g. from the point of view of high-level concurrency based on message passing modelled as an interaction between actors) in the future? Such module could also transparently support other means of message passing than memory copying/sharing, e.g. sockets/network.

I do think it would be possible, and it would have to be module-based, so no syntax support. I think we already have all the components for building such module, someone just have to be brave enough to start building it.

However, it should be noted that message passing modeled on actor model might be too general. It might be necessary to provide more specific patterns in order to be practically interesting. I just had a quick look at nanomsg (http://nanomsg.org), it seems interesting and might be useful for this.

[dumblob]

Yes, nanomsg is a very nice and ultra-lean "framework", but for some patterns it lacks reliability (it's described in it's documentation and Martin Sustrik's blog posts) - e.g. multicast. And it's not planned to make it reliable (just read some blog posts on http://250bpm.com/start/p/2). There is also mangos, an implementation of these "Scalable Protocols" in Go, which should support slightly higher level of reliability, but I didn't check it thoroughly.

[Night-walker]

With regards to pure multithreading (excluding network communication etc.), actor model is trivial to implement. Performance issues, if any, should be resolvable the same way as in most other actor implementations. The complexity would be determined by the amount of features one would wish to have. Thread pool and channels are the only necessary tools for such implementation, everything else is trifles unless you immediately want something comparable to Akka actors or so.

Overall, I again say that having small, simple building blocks (channels, tasklets) is much easier to deal with from the point of language design and more flexible from the point of end use.

[daokoder]

But I prefer not to remove it in hurry, let's give it more consideration, and see if there are ideal use scenarios we have overlooked.

Now it is decided, async class will be gone:)