On Wed, 2017-06-21 at 23:41 +0200, Rick van Rein wrote: > Hi, > > Thank you all for taking my remarks seriously. > > > > [Rob Godfrey] > > From Rick's e-mail I get the impression that he feels there is insufficient > > documentation in order to do the work without support from the Electron(?) > > authors: > > If I've seen everything (broker/sender/receiver code) then it would be > difficult as a basis, yes. APIs tend to harbour "obvious" assumptions, even > when they are well-designed, and I would not dare to barge in based on > working code -- however useful code is as a proof of concept! >
That's everything for now (including the API doc of course) but I would like to expand on it. I am steeped in assumptions from working on Qpid projects so if you can use your fresh perspective to point to specific gaps and questions I'd like to fill them in. I'm sure there are real gaps in the API too which you can help uncover as you look at it from a new angle. > > [Alan Conway] > > I wrote the electron API for Go, and I'd be happy to discuss it further > > with you and offer thoughts on API design, but I don't know any Erlang > > (although I gather Go borrows some ideas from it) > > Go borrowed precisely those things that made you pitch Electron > (which I think is a great idea by the way), namely: > > - OS threads only used to occupy multiple CPU cores > - language-own lightweight threading > - heap-based contexts for many small processes and language support for CSP to shift the design focus of concurrent programming from shared data to co-operating functions: https://blog.go lang.org/share-memory-by-communicating > Erlang also does a few things better IMHO, making it such a great > language for AMQP applications: > > - near-trivial distribution of work over a cluster > - transparant communication on its paranoia-encapsulating platform(OTS) > - garbage collection per mini-proces (for soft realtime responsiveness) > > > Inversion does not suit Go (or Erlang I suspect) so I wrote the > > qpid.apache.org/electron API to be coroutine-friendly, asynchronous, > > but "imperative". > > Erlang uses functional programming, but it is pragmatic in doing so: > > - it sort-of stores data locally in each mini-proces > - it feels a bit imperative (one assignment per variable per context) > - it actually has an imperative dictionary for each mini-proces > - communication between mini-processes adds to their incoming "mailbox" > > The dirty / imperative aspects are often contained in generic > design patterns in the OTP platform. This is where the rich > cruft of concurrency, recovery from faults and so on hides, > leaving the user with a reasonably clean surface to work on. > > > I wrote the qpid.apache.org/proton package while learning Go and > > following the model of the other bindings, but if I was doing it again > > I would write electron directly in terms of proton-C - all the Go > > developer interest is in electron. > > I would expect the same to happen with Erlang. > > > I have a strong interest in extending the "imperative" or "uninverted" > > API approach to other languages - it is ideal for coroutine languages, > > but even with traditional threads I think it is much easier to code > > "moderately concurrent" apps this way. > > Yes, agreed! Processes, like objects, help to structure software. > This is something I love about Go and Erlang. > (Also, CSP-style message passing is simpler than pthreads. Well, > anything is simpler than pthreads I suppose?) You can do CSP-like programming with pthreads but its a lot of heavy lifting. The qpidd and dispatch servers have always been structured as a "sequential context" per connection, and added some ad-hoc extra contexts (qpidd called them "pollable queues") In the current C/C++ APIs we're working towards some core support for a generic "work_queue" abstraction - it is already used internally for per-connection serialization and by making it available to users it makes a C++ broker much easier to write (examples coming shortly!) This is not directly relevant to Go or Erlang yet, but I'm hoping to work up solid CSP-friendly APIs using the native Go/Erlang tools, and the carry ideas back to new/extended C++, ruby and python APIs using work_queues, futures or other emerging tools in those langauges. > can't write any Erlang but I'd be very happy discuss/review API > > proposals, donate my experience from Go and Ruby, and give pointers on > > the C side of things. Once there is some code I can help with getting > > it set up as part of the Qpid project. > > Thank you! > > There are two major sides to Erlang that are involved in porting I suppose, > > http://erlang.org/doc/reference_manual/ports.html > > Ports communicate with Erlang mini-processes from C or Go or... > > http://erlang.org/doc/man/ei.html > > The ei API serialises data passed into / out of Erlang over a Port. > > The language is remarkably easy to learn, by the way... given conceptual > understanding of functional and concurrent programming. I would love to dig into it but don't have enough spare time to learn erlang right now. If you can ask specific questions about the electron doc/design that might be the best way to suck me in. I am itching to be sucked in... > > > Good, time for some soul-searching on my end... like, where to find the time > (or man power) for this useful diversion :-S > > > Thanks, > -Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
