A couple of things came to mind as I read the messages at the flow-based programming group and a discussion at Hacker News. I learned of the HN conversation via an interesting blog post by Samuel Lampa. Among other things, Samuel points out some of the problems associated with what is called "back pressure" in a flow- or stream-based system. This is where the receiver of information becomes overwhelmed and needs to tell the information source that "that's enough, for now" before running out of memory or some other kind of nasty thing occurs.
This got me to thinking about what I'm trying to accomplish with ElixirFBP. It is an experiment to see what a flow-based system written Elixir behaves like and how it can best be designed to offer the user some compelling reason to use such a system - other that it's written in some new language. I think the reason will be the overall speed of computation. This, despite some inherent speed issues with Erlang. Samuel describes how Elixir/Erlang could best be utilized as a "control plane". So, as the discussions above point out, there are plenty of issues to be faced and dealt with. That's a Good Thing! I hope this experiment will result in a base for investigating solutions to these issues.
Stay tuned as I continue the implementation of ElixirFBP support for NoFlo's network protocol. Having this goal of supporting the noflo-ui requires my having to provide a lot of support for the various intricacies of creating and running flow-based programs - something I'm not sure I would have been able to think of on my own.
Finally, it turns out that I can get my code to work with NoFlo's online version of their development environment so one doesn't have to install noflo-ui as I described in my previous post.