We would fail your rule on so many cases. We run Ubuntu, which might be our mistake, but off the top of my head, I think our installations of nginx[1], Python[2], pip[3], rust[4], mongo, consul[4], openldap[1], gcc[3] and several other things fail your criteria. Not all are on the same server, I suppose, but there's definitely overlap. Most of these are simply because the version in Ubuntu is unacceptably out of date, some are because there are bugs in the provided version, some just flat aren't available, and some are re-compiled with additions. (Like, non-default USE flags, if you're a Gentoo user; Ubuntu lacks the concept.)
I think the issue I have with rules like yours, and that proposed in the article, is that they're fine when you're working with no information, but when an engineer lays out a need, shows how the "boring" package available does not fit that need, and then proceeds to choose an "interesting" package that meets the requirements of the problem, the last thing he wants is nebulous objections over how the choice is an "interesting" tech. For example, the article calls out consul (we also considered etcd and Zookeeper…) as an "interesting" choice, but need a multi-node distributed database with a good consensus algorithm for things such as service discovery and locking; what other techs fit the bill that aren't "interesting"?. Consul fits the bill. It's HTTP- and DNS-interfaces interest me because they play well with our existing boring tools, like http (or curl) and dig…
IIRC,
[1]: default package lacks features
[2]: unacceptable issues
[3]: default package too far out of date
[4]: default package is non-existant
Off-topic, but might I ask what you're using Rust for? We love getting feedback on the language, especially so for people crazy enough to use it in a production setting. :)
(I'm also curious exactly how old your version of Ubuntu is, as testing the language on older versions of Linux is currently a bit of an annoyance and it's glad to know that someone out there is benefiting from that effort.)
Sorry about the slow reply. We're using a mix of Precise/Trusty[1]; we're not (presently!) using Rust in a production setting, I'm only using it to experiment currently, but it's still something outside the package manager that _if_ I wanted[5] would apply (and it's tempting…), so I decided to mention it. I'm presently using it to parse an internal file format we have, mostly as a project (one of two) to teach me Rust. (I'm using Rust presently on Trusty & Gentoo presently, both using the binary downloads from the website. I tried brew-installing it on OS X, but that doesn't give me cargo; haven't tried again in a few weeks, and haven't filed an issue…)
While it isn't presently in a production setting, I would be completely willing to put it into production. There are some spots where we need more performance than Python can offer, and the memory safety and good static typing are very appealing (I'm vary wary of memory-unsafe languages anywhere near the path of user input…). (I personally use C++ presently here, but the included gcc in Precise/Trusty IIRC lacks some of the more modern C++11/14 stuff, so heavy use of Boost is needed. Also, some third party libs — mongo, to name one — have less than elegant C++ interfaces…) The Rust standard library has made great strides in the few months since I started using it (I started picking it up in December?), and since my normal work is in Python, the static typing is a very welcome change. I'm still wrapping my head around lifetimes[2][3], regex! tripped me up a bit[4]. I found some iterator based functions — such as zip — odd: it's a member function on the Iterator trait, and only allows two args. I find Python's free-standing zip function which takes any number of iterables much more natural. Compare Python:
zip(a, b, c, d)
to my understanding of Rust:
a.zip(b).zip(c).zip(d)
I also wonder (since I've not tried it) what effect this has on unpacking. Instead of (a_item, b_i, c_i, d_i) being the items of the iterable, I feel you'd end up with a (a_item, (b_i, (c_i, d_i))); I wonder if a destructuring let would be hard on that? (I've not actually gotten that to work…) Also, I wish enumerate had Python's start argument; I use enumerate a lot for doing numbered lists for humans, which start at 1.
Overall, it's shaping up to be quite a language. I sincerely hope it uproots C. (I'm a big proponent of modern C++, and so I'm still attached there. :D)
[1] I really wish upgrading happened faster; I tried to cull items that weren't relevant to Trusty because I do consider Precise out of date. We're limited to LTS simply because people aren't comfortable with non-LTS (and I don't know that we could upgrade quickly enough to stay on a supported OS…)
[4]: https://github.com/rust-lang/rust/issues/23326 — (I had to follow up in the IRC room here, it's not quite as simple as the answer in the issue. Not only do you need to depend on the crate, you need the "#![feature(plugin)]" "#![plugin(regex_macros)]" as _crate_ attributes, and this can be confusing if your use of regex is in a module-in-a-modue-in-a-module; the use of regex in that module (foo/bar/baz.rs) causes you to need to edit a different file (lib.rs).
[5]: one of the things I miss about Gentoo's ebuilds in Ubuntu is that it's so darn easy to throw additional packages into the purview of the package manager. Building .deb files is vastly more complex than an ebuild.
Loving the feedback, thanks! That's a good point about destructuring the returned type of a chained zip, I'll need to take a look at that. And I'm happy that you've found the IRC channel, don't be a stranger if you need help or have any more feedback (especially wrt stdlib APIs that you'd like to see).
I think the issue I have with rules like yours, and that proposed in the article, is that they're fine when you're working with no information, but when an engineer lays out a need, shows how the "boring" package available does not fit that need, and then proceeds to choose an "interesting" package that meets the requirements of the problem, the last thing he wants is nebulous objections over how the choice is an "interesting" tech. For example, the article calls out consul (we also considered etcd and Zookeeper…) as an "interesting" choice, but need a multi-node distributed database with a good consensus algorithm for things such as service discovery and locking; what other techs fit the bill that aren't "interesting"?. Consul fits the bill. It's HTTP- and DNS-interfaces interest me because they play well with our existing boring tools, like http (or curl) and dig…
IIRC, [1]: default package lacks features [2]: unacceptable issues [3]: default package too far out of date [4]: default package is non-existant