Microsoft Continues Porting Visual C++ To Linux (microsoft.com)
Long-time Slashdot reader Billly Gates shared some news from Microsoft's Visual C++ blog: Visual Studio 2017 now lets developers write C++ code for Linux desktops, servers, and other devices without an extension, targeting specific architectures, including ARM:
Visual Studio will automatically copy and remotely build your sources and can launch your application with the debugger... Today Visual Studio only supports building remotely on the Linux target machine. It is not limited to specific Linux distros, but we do have dependencies on the presence of some tools. Specifically, we need openssh-server, g++, gdb and gdbserver.
If I were going to switch to anything other than gcc (or support anything in addition to it), I would first go for clang and then maybe icc. I can't imagine what value vc++ would add over those.
gcc's warning/error messages are pretty awful and I really like that clangs almost always point me precisely to where the problem is, as opposed to where the problem finally made the compiler lose its mind. Does vcc++ improve on clang in that respect? If it does, I could supporting it as a build target for automated builds to get the nice diagnostics (I do this now for a project with clang), but I can't imagine it would be worthwhile for something that gets deployed.
icc is nice if you are on Intel hardware and want the sooper-dooper extra special optimizations, but that is about it.
Each additional platform takes much extra effort
This, exactly.
Since I'm developing for a Linux platform, I already have one of these here. So explain again why I have to drag another platform (Windows with Visual C++) into my toolchain when perfectly good IDEs are available for the native Linux environment.
Have gnu, will travel.
You do realize that most of the complaints you have are basically moving a Linux desktop more toward what MS has done with Windows desktop. PulseAudio bears no small resemblence to Windows Vista+ audio stack (in terms of architecture). systemd similarly resembles the way microsoft services work, journald resembles event viewer design, networkmanager is pretty much the same way Windows does network management, dconf acts a lot like the registry.
If anything, I'd say MS is worse at many of these. As much as I object to journald, event viewer is worse. systemd does make some things more complex, but not nearly so much as the way microsoft handles services. dconf is at least more straightforward and more powerful than windows registry.
XML is like violence. If it doesn't solve the problem, use more.