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! > [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 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?) > I 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. 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]
