Go 1.5 apparently allows one to build shared libraries that could in theory
be linked against other languages. I’ve not tested this, and its not
really a target for mangos (right now at least).
If I ever do the rewrite of libnanomsg, it will probably benefit from many
of the design ideas in mangos. It definitely will be threaded, use a
simpler API that is *not* sockets compatible, and will not be finite state
machine driven. It will almost certainly not use or rely upon asynchronous
I/O, and it will be easier to plug other transports (and possibly
patterns/protocols) into it. It wouldn’t be portable to systems without a
way to express threads or something like threads, and wouldn’t be
appropriate for certain kinds of embedded work (e.g. 16-bit runtimes
without any kind of threading). It would however remain wire compatible
with SP/mangos/libnanomsg.
All that’s theoretical though. :-)
On Thu, Dec 17, 2015 at 10:30 AM, Ω Alisson <thelinuxlich@xxxxxxxxx> wrote:
Mangos can't be compiled to be used on any language since Go 1.5?
On Thu, Dec 17, 2015 at 4:18 PM Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
This was an old question, and going back through the archives, I see I
failed to answer it.
mangos is an independent implementation of the SP protocols — it was
written from scratch to be wire compatible, in idiomatic Go. It will
remain so for as long as I am the owner/maintainer of it. I have also
explored some other capabilities, such as adding SP over TLS, and
integrating within the Go websocket and HTTP frameworks. Those would be
unrealistic to accomplish using libnanomsg. (Also, by being idiomatic, it
quite likely outperforms native C / Go translation, and certainly fits
better within the Go concurrency model.
None of this is affected by the fact that I’m also now the libnanomsg
maintainer. Apart from sharing specifications, the two projects will
remain independent.
libnanomsg was started by Martin Sustrik, who also wrote the vast
majority of the code. Its more a community effort these days, and while
I’ve taken on a “benevolent dictator” (maintainer) role for it, that’s not
a position I’m happy with. I’d be happy to either step down, or share
leadership at some point, for libnanomsg. Right now the single biggest
hurdle here is getting sufficiently expert contributors who have both time
and interest to step up and share this responsibility. I suspect there is
at least one individual here who would make a good candidate for at least
joint “maintainership”. (I’ll reach out separately.) It’s unfortunate
that the libnanomsg is as complex as it is; its unapproachability is
perhaps the single biggest problem with it. (That nice friendly sockets
based API you all love is backed by a hairy beast underneath.)
mangos is different. That’s my project, and while there have been some
good contributions, I feel a much stronger sense of ownership. Whereas
working on nanomsg is a job that I often detest, as its difficult and the
convoluted state machines are definitely not how I’d like to implement
things, mangos is the opposite for me — I truly enjoy working in that code
and indeed I often resent the time that libnanomsg steals from me that I’d
rather be spending towards other ideas I have for mangos. So even if I put
mangos into a top-level github org repo, I don’t intend to change the BDFL
nature of its organization. The top-level github account is more about
wanting to make the project more readily discoverable, and to reserve the
name against any future where I might not be the maintainer. (Nobody lives
forever, and I imagine at some point I might want to move on — even if I
can’t imagine *when* that might be.)
As to a hypothetical rewrite of libnanomsg, I’ve spent some effort
thinking about this, and even written some initial code. That project, if
it ever takes off, will probably be independent of libnanomsg proper as
well. Because it would have different design goals, and an incompatible
API. However, assuming that I ever do such work, I might then be willing
to discuss whether it becomes some kind of “semi-official” or even
“official” successor to libnanomsg, and if it did that would I then be open
to a more open governance model for it. But in any event, such a rewrite
remains strictly hypothetical at this point, and I wouldn’t plan on seeing
it any time soon. Indeed — sustaining tasks on “current” libnanomsg are
sufficiently time consumptive that I really have no time to take on a new
major open source coding effort — I don’t even time to allocate to the ones
I want to (which are various — from illumos kernel projects, to Go based
terminal stuff, to mangos, and even a game I wrote in Go — and yes I resent
libnanomsg from stealing time from all these tasks and interests.)
I hope that clears up some questions for folks.
— Garrett
