Go language implementation of FBP without the use of frameworks

[Phil Ruggera]

Here's someone who is using the Go language to implement FBP without the use of frameworks: https://appliedgo.net/flow2go/

It demonstrates the built-in support of concurrency primitives in the go language.  I'd be interested in your thoughts on his implementation.

Code at github.com/appliedgo/flow2go

[Paul Morrison]

In TIOBE, I notice that Go is the fastest climbing language - at #10, up from #55 this time last year!  Interesting!

The top 6 are steady: Java, C, C++, Python, C#, PHP.  JavaScript has dropped from #7 to #8, basically switching with Visual Basic .NET.  My (somewhat murky) crystal ball says it will probably drop further...

Maybe we need to work on a "classical" FBP implementation for Python...!  Or is there one out there?

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[paul tarvydas]

On Jul 23, 2017, at 4:04 PM, Paul Morrison <jpau...@gmail.com> wrote:

In TIOBE, I notice that Go is the fastest climbing language - at #10, up from #55 this time last year!  Interesting!

The top 6 are steady: Java, C, C++, Python, C#, PHP.  JavaScript has dropped from #7 to #8, basically switching with Visual Basic .NET.  My (somewhat murky) crystal ball says it will probably drop further...

Maybe we need to work on a "classical" FBP implementation for Python...!  Or is there one out there?

https://wiki.python.org/moin/FlowBasedProgramming

[Paul Morrison]

Thanks, Paul T!  Apologies, Phil, I hope I haven't diverted the conversation from Go!  Let's stay with Go for a while!

Paul M.

[Phil Ruggera]

A big challenge with "classical" FBP is the overhead of all the Information Packet queue processing between every node.  Go is a language that may minimize this overhead because of its builtin concurrency and channels.  But the benefits of FBP have to be significant enough to overcome this architectural overhead. 

[Paul Morrison]

Hi Phil,

I am wondering why you think the overhead of the IP queue processing between every node is high...?  

I have written quite a few FBP schedulers, and most of them use a ring structure for the queues,  where

   "send" results in -                 store IP pointer in slot pointed at by "next put" pointer
                                                move "next put" pointer to next slot in ring

   "receive" results in -             get IP pointer from slot pointed at by "next get" pointer
                                                mark that slot empty
                                                move "next get" pointer to next slot in ring

In the ring structure, an empty ring is detected by "next put" == "next get" and slot pointed at is empty,
                                 a full ring is detected by "next put" == "next get" and slot pointed at is occupied

Of course the larger the ring is (capacity of the connection), assuming smart scheduling logic, the less often you have to switch between processes.

In conventional (non-FBP) systems, the nearest equivalent to a "send"/"receive" is probably a call (with all its disadvantages!), which also has overhead.

But maybe I didn't understand your point...?  All my schedulers are open source, so feel free to try changing the scheduling logic to see what performance changes you see.

Regards,

Paul M

[Meng-Han Ho]

Most of FBP implement on python wiki list are out dated. There seems to have no on going python implement now.

I would really love have a python implement of PFB, since most of software I use only provide python API.

As for GO, there are go-fbp and goflow on github, suppose to work with drawFBP, but I've not tried it yet.

Paul Tarvydas於 2017年7月24日星期一 UTC+8上午5時26分58秒寫道：

[Samuel Lampa]

 This is something I've done for a few years already.

As mentioned in the flowbase README, I blogged about this in two posts in beginning and end of 2015:

https://blog.gopheracademy.com/composable-pipelines-pattern
https://blog.gopheracademy.com/advent-2015/composable-pipelines-improvements

... and finally created a library of it in mid 2016:
https://github.com/flowbase/flowbase

... which I successfully used to build a Go based tool to convert from RDF to Semantic MediaWiki markup:
https://github.com/rdfio/rdf2smw
(See these lines for the connection setup: https://github.com/rdfio/rdf2smw/blob/1e3161/main.go#L114-L139 )

Not sure if the post author was aware of it :)

Anyways, it is an approach I'm a heavy fan of.

I'm hoping to extend FlowBase with more FBP best practices as we go, but I like the approach to start with the basics and see to what extent we can just leverage the existing primitives in Go, to keep maintenance burden at a minimum (which is my main worry keeping me from jumping on complex frameworks without major communities or organizations backing it).

Best

// Samuel