For Mail/Calendar/Contacts/Tasks you should really consider Evolution. I've switched ~2 years ago, and it's amazing. Stable, sleek, and with tons of options.
It has a bad reputation because, back in the day, it was buggy and bloated. But I haven't hit a single bug over these years, and while it eats a significant amount of memory, it's on par with other options (and these days everyone has plenty of RAM).
I'd love to see more people giving it a second chance.
Centralization is a _huge_ privacy issue. Specially when combined with real world data, like a phone number.
Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications?
Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands.
If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.
That comes from upstream's README.md. I've never payed any attention to it, but now that you've pointed it out, I'm seriously considering changing that paragraph, or adding a note/disclaimer somewhere.
After all these years and promises, server's code is still closed, federation is nowhere to be found, their update/commit policy for the official Android app is a joke [1] (they even closed its issue tracker), and I'm really tired of their "trust us, we're not evil" policy [2].
If you haven't switched to Matrix/Riot, do it right away.
Telegram-FOSS (the FOSS friendly fork you can find on F-Droid, not the official app on Play Store) maintainer here. Telegram is NOT a "secure messaging app".
Three days ago, a Jolla C replaced an iPhone 5S as my main phone. To be fair, me using iOS was just a kind of an experiment. Before that, I was using a CM build without Google Apps using FDroid as unique app repository.
I must say that, while still needs some polishing, Sailfish OS (which is not 100% free, but is quite there, and provides a complete Linux experience), does the job. My Pebble works, my BT car kit works, and I have all apps I need. In fact, my biggest complain is about the hardware, being underpowered and with an atrocious camera. An official port from Jolla to some mid level device would make me _very_ happy.
In some countries, like mine, the FOSS mobile OS killer has a name: WhatsApp. Without official support for FFOS or Ubuntu Touch, and being very aggressive against third party apps (banning their users), most people can't even think of them as an option for daily usage.
Jolla goes around this bundling a commercial Android Dalvik emulator. Not the best solution, but one quite pragmatic.
At flexVDI, we use Xamarin for building our macOS client (Xamarin.Mac), sharing most of the code with the client for Windows, built with Visual Studio. Both of them, link against a shared library which implements core functionality, written in C.
I must say that, having its own quirks and nuisances (specially in Xamarin Studio, which was pretty buggy until version 6.x), it does the job pretty well.
In fact, when we wrote our iOS and Android clients, Xamarin was still pretty immature. But if we had to rewrite them today, it would be one our of first options, right after using the native frameworks (which ensures the best results, but drastically increases the costs).
I'm not talking about the efficency of the resulting binary, but the "distance" from what the programmer is thinking, to what the machine will really do.
Compiler optimizations aside, C does a pretty good job at this. It's way more efficient than writing assembly, but your still basically just moving memory around, while doing some arithmethic. Easy to understand in "machine" terms.
Of course, this is only relevant when you're doing low-level stuff, like kernel or drivers programming. For the userland, Rust really looks like a nice language (I've played with it just a bit), and I'd be really happy if it pushes C++ away ;-)
I can't help but think they're trying to fix something that isn't broken at all.
Adding new abstraction layers rarely helps when doing systems programming. You (as in "the developer") want to be as near to the machine as possible. C does this pretty well.
Sorry if I'm too harsh, but saying that ZoL is "rock solid" and "production ready" sounds like a joke to my ears.
ZFS is an extremely complex filesystem, and it took Sun _years_ of internal testing first, and hundreds of angry customers later (sadly, at some point, the only way to improve a product is through real world testing), to reach a milestone where it was really production ready.
I know that on these days of dockers and unicorns, "production ready" has very different meaning than years ago, but still...
The OSF vs GNU Mach thing is not a problem. It was years ago, but I managed to run a Hurd translator statically linked against a slightly modified glibc on OSF Mach (the one bundled with MkLinux, you can see its code on my repo https://github.com/slp/mkunity).
In fact, if you look at Mach support code on glibc's code, you'll see build time conditionals for supporting non-GNU Mach versions.
The bootstrap server is not a problem either, but the lack of memory object would indeed break all libpager based translators, among other stuff.
As a PoC, I wrote a filesystem translator (https://github.com/slp/anonfs) which doesn't rely on memory objects, implementing conventional read/write semantics (no mmap() support, though).
A curious (and probably unintended) side effect, is that if its implementation of the Mach API is complete enough, this should allow to run Hurd user space server/translators on FreeBSD.
Not sure if useful, but would be cool (in a weird, nerdy way) anyway.
It has a bad reputation because, back in the day, it was buggy and bloated. But I haven't hit a single bug over these years, and while it eats a significant amount of memory, it's on par with other options (and these days everyone has plenty of RAM).
I'd love to see more people giving it a second chance.