Nanomsg postmortem and other stories
sealedabstract.com
Nanomsg postmortem and other stories
1–10 of 32 posts
Re: Nanomsg postmortem and other stories
#2nanomsg was an interesting successor to the bloated/C++/LGPL zmq, but it succumbed to old ways that don't work anymore.
It's 2016 and you can't run an (intended) global-scale open source project by just being "code nerd in chief." If you can't run an open feedback-driven community and if you can't be chief architect (also means communicating plans constantly, not just 'do whatever you want') and if you don't possess technical and professional excellence (also means being responsible with security issues and timely resolving of user issues), then you don't actually have an "open source project," you have a private uploaded code repository other people can see publicly.
Gone are the days of 1995 when you could live on an island and upload your new code once per year and everybody would leave you alone and praise you in computing magazines for being a genius. Now you'll have 1,000 issues on GitHub and requests for public appearances and proposals for changes and important security flaws to fix and requests for extensive communication about current designs and upcoming features.
The whole "i'm going to do this all on my own, everybody else go away it's my code" doesn't work anymore. Those projects are now destined to fail on their own without open and scalable community leadership. The good projects "get it" and the old guard are toppling as we speak. In another two years, nobody will trust open source projects without a stated scalable community model and codified successorship plan.
Re: Nanomsg postmortem and other stories
#3once again i see the "no matter what they tell you, it's a people problem" issue. very nice analysis of how to reach this conclusion from a very technical position.
Re: Nanomsg postmortem and other stories
#4Very interesting read: worth the time.
See also: http://hintjens.com/blog:112
Re: Nanomsg postmortem and other stories
#5Yeah I dunno, the "solid technical reasons" are pretty unconvincing. The reasons are:
1. Exceptions are awkward because they separate the error handling from the context that is usually required to correctly handle an error (i.e. where it occured).
2. Exceptions are the only reasonable way for a constructor to fail. You can't return error codes from a constructor.
I actually agree with the point about exceptions, and I'm glad Rust didn't use them. That said, the solution is trivial (and the author admits it) - don't use exceptions.
The second point is also actually a fairly good one, and again Rust has fixed this - it uses static `new()` initialisers that create object (or not, if they fail). Fortunately we can actually copy this method in C++. Here's an example for a network connection object:
class Connection
{
public:
static boost::optional connect(string host)
{
// Try to connect.
int connectionHandle = -1;
int rc = connect(host, &connectionHandle);
// If it fails return none.
if (rc It seems pretty crazy to give up C++ for these fixable flaws. Especially given how many unfixable flaws C has.
Re: Nanomsg postmortem and other stories
#6Projects have to drive unbelievers out to work. Well, partly. It does not matter if someone is just not believing in one specific aspect of the project and ignores it. That is fine. But when the group starts to fight over what to do instead and this agreement can't be reached, then a split is necessary to enable common work of the people left.
Of course that can't work when the project has no working governance, if the project has not even a clear goal. If a project is only defending against unbelievers without having a consensus of its own. And I think that is what he is mainly describing here, without me being sure that is fully intended.
Re: Nanomsg postmortem and other stories
#7Yeah I dunno, the "solid technical reasons" are pretty unconvincing. The reasons are: 1. Exceptions are awkward because they separate the error handling from the context that is usually required to correctly handle an error (i.e. where it occured). 2. Exceptions are the only reasonable way for a constructor to fail. You can't return error codes from a constructor. I actually agree with the point about exceptions, and…
Your connect method can still throw std::bad_alloc.
Re: Nanomsg postmortem and other stories
#8nanomsg was an interesting successor to the bloated/C++/LGPL zmq, but it succumbed to old ways that don't work anymore. It's 2016 and you can't run an (intended) global-scale open source project by just being "code nerd in chief." If you can't run an open feedback-driven community and if you can't be chief architect (also means communicating plans constantly, not just 'do whatever you want') and if you don't possess…
Really? The whole thing used to be about fun. Like, "hey look at this!". Do you really need press secretary and events coordinator? If you were running a business, yes. That was the entire concept of enterprises like Red Hat and Canonical, even parts of Intel and IBM. That is, repackage and support semi-organized hackery.
Again, we don't want to devolve into the bureaucracies F/OSS usurped. (Ideas + fun + seeking prestige + curiosity) * tenacity = occasional glory.
Re: Nanomsg postmortem and other stories
#9nanomsg was an interesting successor to the bloated/C++/LGPL zmq, but it succumbed to old ways that don't work anymore. It's 2016 and you can't run an (intended) global-scale open source project by just being "code nerd in chief." If you can't run an open feedback-driven community and if you can't be chief architect (also means communicating plans constantly, not just 'do whatever you want') and if you don't possess…
Really? The whole thing used to be about fun. Like, "hey look at this!". Do you really need press secretary and events coordinator? If you were running a business, yes. That was the entire concept of enterprises like Red Hat and Canonical, even parts of Intel and IBM. That is, repackage and support semi-organized hackery. Again, we don't want to devolve into the bureaucracies F/OSS usurped. (Ideas + fun + seeking pre…
It's a matter of scale.
Of course you can put anything you want up online (and you should!). But, if you have (or expect to have) millions of users, then one person sitting alone saying "ME ME ME" doesn't cut it.
It stops being less about fun when your company loses $10,000 per minute of downtime and you suffer an outage because you are operating "at-scale" (256 GB RAM to 1 TB RAM, thousands of clustered servers, multi-datacenter replication, etc) but your software is only tested on the primary developer's macbook air.
Rejecting the feedback of people with actual experience running large scale systems in favor of one person's unexperienced narrow viewpoints is just bananas. Large scale software can't operate under single minded "open source fascism" anymore because our computing world is too complicated these days.
With millions of users you'll have people using your software for critical systems needing things like uptime, reliability, timely security fixes, timely bug fixes, etc. When you start getting 50 requests a day for changes, you will seem inept just telling everyone "lol its my software i do whatever i want you should just go away and fork it you can't tell me what to do."
It's professionally irresponsible to run a project with millions of users without a scalable team of equal contributors.
The argument against companies running their systems on top of poorly maintained/developed/supported open source software (while still expecting free and immediate improvements/fixes) is an entirely different article though.
Re: Nanomsg postmortem and other stories
#10I personally traveled to Slovakia to meet with Martin, Mato and Pieter, a few years ago. I commissioned them to fix some annoyances I had with ZeroMQ.
I just want to say that they are all great people, they're very smart and have spent a lot of time deeply thinking about messaging.
I was really hoping to use nanomsg at some point, so I'm a bit disappointed to see all this. Really hoping that someone (Drew?) releases a new BSD licensed library.