Microsoft previews Visual Studio update with added Linux love, many new features Microsoft's second preview of Visual Studio 2019 16.5, freshly flung out this week, has better Linux support for C++ developers and also includes a new designer for Windows Presentation Foundation (WPF). Visual Studio is updated every two or three months. Version 16.4 was released in early December so you can expect 16.5 to …
Hello:
... an increasingly common pattern ...
A huge mistake.
This crap should not be allowed to interact with Linux in any way.
Why is Microsoft putting effort into C++ development tools for Linux?
Because it is doing what it has done for the better part of the last 30 years:
Embrace, extend, and extinguish
... forcing them to develop in a Linux environment directly would be a difficult ask ...
If you develop for Linux, you develop in a Linux environment.
Period.
But yes, it's probably a difficult ask ...
... for developers who are not worth their salt.
ie: not really developers.
O.
Good grief, it's like a stuck record.
This crap should not be allowed to interact with Linux in any way.
Are you suggesting that your subjective opinion should somehow authoritative for all Linux, Linux developers?
Because it is doing what it has done for the better part of the last 30 years:
Embrace,
Yes...
extend,
which is nice of them, and oh I'm sure they'll comply with whatever open source license terms there are,
and extinguish
No. You think that, somehow, MS making a different way to develop in C++ for Linux is somehow going to delete Linux, GCC, GCLIB from off the face of the earth?
If you develop for Linux, you develop in a Linux environment.
Sigh. For whatever you mean by developing in Linux, this is. You can't get much more Linux-ish than cmake, gcc, gclib, etc. It is developing in Linux, in case you hadn't noticed, even in WSL. It's not even cross compiling.
By your argument, anyone using any editor based on the Electron framework is developing for Linux in Javascript, or Facebook, or whatever, or someone developing for Android should be forced to use their mobile for the purpose.
As it turns out, quite easily. Simply because the build environment itself isn’t Windows, it’s Linux. Visual Studio is using ssh to push files up to the target Linux environment and building the code there. None of this involves compilers or linkers on Windows, and you can use cmake to control the build on the Linux target. Alternatively msbuild can call the target’s g++ through ssh if, for whatever reason, msbuild was the thing one wanted to use.
Go the cmake route and you can end up with a git repo of files that can be built entirely on Linux entirely without Windows and Visual Studio. So you’re not even stuck forevermore with MS.
None of the people who I know who develop for linux do so using linux. Most of them use OSX on the MacBook Pros.
And that's part of the answer to your question; if you buy a laptop, chances are it'll either run Windows or it'll be a Macbook*. Most likely, they'll keep that OS, because it's just easier than having to try and work out what set of binary blobs you'll need to get the wireless to connect, or to get suspending to work, or to get sound**.
So they develop on Windows or OSX, and they push it to the server running linux.
(I'm not a developer, but I work on a Windows machine, to administer many linux boxes).
* and yes, System76 et al. do exist, but I'd be surprised if they sell in a year what Apple shift in a day.
** I jest of course. Everyone knows that you can't get audio working on linux.
I've worked on cross platform Windows and Linux applications in the past, and am actually doing so now in my current job. Today I use Visual Studio 2019 on Windows, and Visual Studio Code on Linux. Being able to build and test on both machines from one IDE would be a much better experience for me. Not least the ability to test things on both platforms without having to either push and pull a private branch in Git or otherwise manually sync the files between the two platforms.
Linux development with C++ is supported in Visual Studio 2019, using either a remote machine or Windows Subsystem for Linux (WSL), [...]
Great! Now you can infect the Linux platform with code written with a never-gonna-be-standards-compliant C++ compiler. Nah, I think I'll stick with ISO-compliant compilers like g++ and clang, thankyewverymuch!
And then there's this:
"At EA our game developers are used to a Windows environment for development so we thought that forcing them to develop in a Linux environment directly would be a difficult ask, [...]
Yeah, I can see that; having to ask a team of hopelessly brain-addled, MS Kool-Aid drinking devs to actually learn the language they purport to be "experts" in might just be too much to ask....
If you look at this list, the Visual Studio compiler is as compliant as both gcc and clang for new c++17 language features, and *more* compliant as far as the c++17 standard library is concerned.
It is apparently lacking full support for C11 (which I don't give a shit about), and constexpr (which I haven't noticed).
Even after reading the comments so far, I can’t for the life of me work out why you would develop on Windows to deploy on Linux? It’s bonkers
I’ve developed on Windows to deploy on Nucleus. And I’ve developed in Linux to deploy on vxworks. But Nucleus is tiny and as far as I know doesn’t even have an editor written for it (but it might) and vxworks is eye-wateringly expensive so it’s not practical to have it on every desk. But these are both specific cases. In contrast, Linux is a full os and costs nothing and Windows is shite if you’re developing for Windows, so why the hell would you use it to write Linux stuff? It’s brain-dead stupid
Regarding Nucleus and VxWorks, the whole point is that you don't compile on platform. Especially VxWorks. Before this innovation of building off-target came along the target had to be big enough to both run and build code. This is how OSes like OS/9 worked (yes, confusing when IBM's entirely unrelated OS/2 came along...). That meant that developers had special development targets (more RAM, more storage, etc) on which they could do building and debugging, and then you'd burn the built code into an EPROM (this is a long time ago) and you'd see if it still ran on the real target hardware. If it didn't, generally you were screwed.
VxWorks / Tornado was one of the earlier RTOSes to properly sort out cross-compliation, off-target tools hosting. In some ways, the debug arrangements for Tornado on Solaris have not been equalled.
Also, these OSes have never been intended to be general purposes desktop OSes.
Linux might commonly be a full up OS on which you can develop, but often in the embedded world it isn't. Things like yocto linux is all about cross-compiling for Linux targets.
With Visual Studio's hook up one can go part way between on-target and off-target development. If the target is up to compiling the code, it doesn't have to be any bigger in order to also host debug / IDEs - that's Visual Studio off on one's Windows box.
I've tried out hooking up Visual Studio to Linux, and it's actually quite nice. It's not even cross-compiling - it's simply a way of remotely (through ssh) marshalling use of standard tools like cmake, g++ on Linux. The earlier version I tried was only slightly irritating in that Intellisense couldn't ordinarily see inside Linux's header files (unless you copied them over and directed Visual Studio at the copies, or somehow otherwise exposed them to Windows in a fileshare or something). Apart from that, it was excellent. I gave it a go after getting frustrated with a (no doubt temporary) balls up with things like EclipseCDT on Fedora being incompatible with the gdb that Fedora was also shipping. Visual Studio was perfectly OK.
Windows is shite
There are many respects in which Windows is technically superior to Unix-like systems. That's hardly surprising given that Unix was designed in the days of paper tape and teletypes and is stuck with some of those concepts to this day. As a consumer operating system, it's also demonstrably superior in terms of its support for a wide range of hardware. It also suffers from being inextricably linked to a desire to extract money from its users, to a specific processor architecture (mostly) and to maintaining legacy features that make it unnecessarily complicated, but placate a lot of users.
However, most of that is irrelevant in terms of its suitability as a development platform. It's simply a consequence of its history that Visual Studio runs on Windows rather than any other OS. When it works (and as it becomes an increasing behemoth, that is increasingly infrequent) it is head and shoulders above any other development environment I've used - and I've used a lot. The community editions are also free.
The question really is why would you not use free tools that improve your productivity? I can see an argument for that if you were forced into irrevocable dependence, but that isn't the case. Just switch your toolchain later if you fancy a change. As it happens, I don't use Windows any longer as I don't like the direction Windows 10 has taken - and I no longer have access to the corporate versions that mitigate some of my concerns - but to dismiss the development tools using the highly technical argument that "Windows is shite" rather suggests that you haven't given the matter serious thought.
Do not confuse the fact that tens of thousands of developers have desperately tried to make something that works and is useful under Windows with any technical superiority. Linux is demonstrably superior to Windows and you only have to look at Azure and the fact that its networking is managed by Linux boxes to realize that.
Yes. Microsoft uses Linux to manage Azure. Let that sink in.
You know what "the days of paper tape and teletypes" had ? Reliability. That is what Linux has, and that is what Windows will never have. One day, businesses will wake up to that fact, when the new generation that has not been brought up on Windows comes of age and starts managing things.
Well you’re right - I’ve not given it serious thought. It doesn’t deserve it.
And if my target machine is a tiny Linux system (which is quite often the case these days), I use a big Linux box to do the dev work on. It’s nonsensical to use Windows for this. And I’m not at all taken in by some shiny shiny Visual studio thingie; I’ll stick to vim and a command line thanks - much more efficient
It's for those enterprises where everyone is forced to use a Windows desktop, devs are getting sick of it as their job is to make Linux software, and there's a danger of the dam bursting and Linux seriously being used on the desktop and not found wanting. Once people find it's not terrible, others could join them.
But now, the PHB can point to this and life can carry on.
"At EA our game developers are used to a Windows environment for development so we thought that forcing them to develop in a Linux environment directly would be a difficult ask, so we decided to use clang and cross-compile from Windows and target Linux,"
Funny, I know some guys at EA. They tell me it is company policy to use Visual Studio and Windows. It sure sounds like *someone* is inflexible and old fashioned.
We take a fundamentally different approach to tooling - I understand, that this causes more maintenance effort but the resulting increase in productivity and happyiness ahs until now outweighed it by far. It may be hard to scale though.
The "normal" stuff:
For every project
- there exists a defined repository (duh). What's not in there dosen't exist.
- there exists an automatic build and deploy process to a defined set of targets (usually VMs, that are spun up from a template). What doesn't build there doesn't count.
- Deep testing in development is encouraged, but only the tests on the targets count
The "strange stuff":
Every developer choses whatever tooling he wants to fill the repository. Choise of Hardware (within a budget), OS, IDE, tools whatever are completly up to the developer. Want to develop in nano via SSH? Go ahead. Want Visual Studio? Go ahead. Use whatever makes you happy, but remember that the build target isn't your machine, but the project build-and-deploy bot.
Some chose to "make things run locally" first and then basically port to the target, others keep very close to the mothership - I don't care. It's the output and dev happyness that count.
Quote: "... build on WSL but deploy and debug on a second remote Linux system over SSH..."
*
So......why would anyone do this....when they could use the "second remote Liunx system" DIRECTLY FOR DEVELOPMENT?
*
Does "Embrace, Enhance, Extinguish" ring any bells?
*
Take a read of the (now long forgotten) Microsoft email tiltled "Evangelism is War".
*
So......no changes at all in Redmond, WA since the days of Bill Gates. Why am I not surprised?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
