What will C++17 be?

I'd suggest looking at the papers that were submitted for discussion at the upcoming Lenexa Standardization meeting for references. They're located here: https://isocpp.org/blog/category/standardization

Here's numbers for the ones you listed:

Concepts: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n436...

Modules: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n446...

Coroutines: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439.... Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n413...

operator dot: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...

Uniform call syntax: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...

Here are some others that Stroustrup listed. I think they're probably important proposals. I imagine Stroustrup has at least some priority order in his list.

Ranges: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n438...

Comparisons: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...

array_view: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n434...

It's frustrating having the proliferation of different package managers.

Each one can work well in isolation; but when you then need to integrate with your platform package manager or another language's package manager, you get a combinatorial explosion of possible interactions.

One example that I've been particularly frustrated by recently is Python/Emacs integration. I have Emacs and Python installed via my system package manager (apt). Then there are a bunch of Emacs modes that I need to install via the Emacs package manager (elpy and its dependencies). Those in turn have dependencies on Python packages (rope/flake8). And finally I have a bunch of different python packages that I work on that are all linked to from a virtualenv so that they'll all resolve properly in all of those tools.

If I upgrade one part of that system (apt, emacs packages, python packages), it frequently breaks other parts, because there aren't any proper dependencies between them. I then have to spend a while fiddling with the whole setup to get it back up and running again.

Basically, the more package managers you have, the less value they have. The whole point of package managers is to manage a whole set of packages together, so you don't have to manually go through and resolve all of the dependencies yourself, manually figure out which version of this package goes with what version of that package. But every time there is some dependency between two different package managers, that breaks down.

Another part of the frustration is that they are all basically doing the same thing, but with slightly different implementations. In the end, a package manager's purpose is to let you figure out which packages you need, by resolving dependencies while honoring version constraints, fetch those packages from an archive somewhere (and verify that they are intact and haven't been tampered with), unpack them and install the files in the right places, and run some glue code to set up indexes, documentation, and so on appropriately. The only part of that task which really needs to differ between package managers is that glue code, plus the policies for inclusion in the centralized archive; everything else is basically solving the same problem in a whole bunch of slightly different ways (different ways of representing and comparing version numbers, different ways of verifying package integrity, different ways of doing local mirrors, etc), and so you get a whole bunch of incompatible and differently buggy implementations of the same kinds of things, or some functionality just missing from certain package managers.

What I would really like to see is a single unified package manager core, that handles all of the basic functionality that they all set out to solve, with the ability to utilize multiple different repositories (so that different projects could have their own policies for inclusion and sets of packages that are designed to work together), and appropriate places to hook in all of the language (or distro) specific glue that you need. I've been mulling over trying to write such a package manager, but of course when doing so you need to be careful or you will run into this problem: https://xkcd.com/927/

> Typically installing Linux from scratch has involved less fiddling with drivers than installing windows from scratch on an empty laptop for a while now.

Windows 8 has worked out of the box on every configuration I've tried, with the caveat that it installs non up to date drivers (e.g. High end graphics cards). My experience with Linux (Ubuntu 15.04) is that the little use peripherals I have don't work at all ( I've a Bluetooth usb adapter and a usb capture card that both are plug and play on windows vista onwards but I've yet to find working drivers on Linux for).

> I think what people want is something like go, where you add a single line to your code and it magically downloads and compiles the referenced library.

Not like Go. It needs to solve versioning.

Oh, I know why it keeps on happening, but it leads to a frustrating and fragmented experience. That's why it would be nice to have a common core package manager, that handles all of the tasks that any package manager will need to handle (metadata, versions, dependencies, dependency resolution, conflicts, features, fetching packages, verifying packages, managing an archive of packages, etc), plus the ability to hook in at appropriate places to provide the distro or language specific hooks necessary, and the ability to have cross-archive dependencies (including union dependencies like "either these three Debian packages, these two Fedora packages, or this Homebrew package"). That would then let you focus on solving the common problems in one place, and leave each language or distro to only have to focus on its own particular glue and policies.