The code for Visual Studio is just incredibly well architected. It is a design jewel - the core components are independent of the UI, and were already cross platform. It was a great surprise for us.

What you see now is the first drop, we are adding many new capabilities in the coming months as more code is ported over.

Step one level up above the trenches and the people you meet haven't had the time (or even skills) necessary to study the details to determine the fact that "Visual Studio for Mac" is, in fact, not the latest version of Visual Studio in the slightest. And why should they. Delivering a visual studio solution should be as unambiguous as delivering an excel sheet.

Then I need to ask... why is it so bloated and slow?

I realize that architecture can't be separated from functionality, but I think the parent was focused on modularity and the ability to reuse various components.

0: https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu...

Visual Studio for Mac is built as a series of components on top of the open source MonoDevelop.

When we touch the core, it goes open source, and some of the extensions like Android and iOS development are closed source.

Is there a roadmap for Xamarin Studio?

> Our goal with Visual Studio for Mac is to create a native IDE for Mac users...That means "desktop app" development will target macOS.

Feedback: This target ghettoizing mentality seriously hurts my workflow. I just want to cross compile to target Windows. I want to make Win32 MFC C++ executables without having to boot into an operating system (Windows 10) that I never want to use on my development laptop for anything other than running MSVC. It's literally just a set of headers and object files that will, in even the very worst case, produce more applications targeting your platform. Why does Microsoft continue to keep them walled off?

Isn't the answer obvious? How many MFC devs are there working primarily in OSX or linux? It has to be tiny, even if they had the ability to do so. Great, I can compile; still need to boot up Windows to run it. My userbase is still 100% windows users. We still use Windows on every PC in my company. So who cares? What's the value proposition here?

None, because you can't, the same reason you don't see many iOS developers using windows. I don't know if there are many people that want to work that way or if it's worth supporting, but your current argument is circular reasoning at it's finest.

C'mon, how is this not completely obvious...

...

What, Fedora?

What's the point, you can't debug or even run such an executable? What developer is just going to compile stuff without testing it? It makes no sense to want this.

I can and I do. Don't be so unimaginative.

For starters, Wine actually works really well. And beside that, time spent writing code is measurable in weeks while time spent running an executable to test or debug is measurable in minutes. The amount of time spent testing and debugging is a tiny fraction of the time spent coding. RDP/VNCing for one of them every second of the day can be a huge pain in the ass. Doing it for the other once in a while is a minor inconvenience.

Next time just say "I'm glad I don't have that problem" instead of "You can't possibly". A mindset like that ends up making you look foolish, because you'll be wrong most of the time.

That said, we also have to be able to encourage others to present their ideas. We clearly can't grow if we don't hear and consider external ideas. It's a difficult balance to strike.

Maintaining two separate development environments, on two operating systems that you have to boot into separately is very annoying. Developing for an operating system other than the one you're running is about as old as the personal computer, I think :).

If time and cost was no option, sure I'd agree with you. Put everything on everything. But this is such a niche situation that's not worth the cost.

This is a niche situation only because Microsoft's tools make it a niche situation. It's pretty much how all embedded software on this planet is developed (except that the network is replaced by a serial connection on the lower end of the performance spectrum, of course). In nix world, it's a super-common situation; e.g. at $work, where I write software for networking equipment, no one seriously expects that I'm going to compile stuff on the routers that ends up running that software. Most of them are capable of the required heavy lifting (they have CPUs in the same performance class as a pretty beefy desktop), but why?

The question is backwards. The real question is, why doesn't Microsoft do what is necessary to bridge them. And the answer seems to be simple -- developer man-hours are limited, your use case is not the use case of the majority of people who want a Microsoft development environment on a Mac, they are handling the most common use case, not the edge case.

I don't think so. Win32 with MFC is already in the free VS Community Edition on Windows, so we know that the work to package up those libraries is already done. We also know that Clang and GCC can already cross-compile targeting Windows, all you need are the aforementioned platform libraries.

I guess I don't understand what sort of developer workflow you can have building windows apps and not actually running windows, even if it's just in a vm.

How are you going to test your program?

I never believed in cross compilation without testing.

My language settings are:

1. English - Canada

2. English - UK

3. French - Canada

4. Chinese - Simplified

apparently the installer wanted people to practice the languages they've been putting off.

Our focus for the initial release was to get our .NET Mobile, Cloud and Unity components in place.

We have a solid pipeline of new features, stay tuned for more details on my Visual Studio for Mac talk today.

It sounds like its BASED on the same IDE, but fundamentally provides a completely different feature set, and ability to compile to completely different platforms. That's fundamental enough to suggest its not the same IDE.

If anything, MS is simply capitalizing on the brand recognition, and taking a similar approach. But if the extensions don't work on Mac - its not the same.

That's like saying "Microsoft Word, the same word processor you love, on a mac" and then not support .docx files.

Btw pretty excited about the visual studio for mac as current visual studio code user and a huge typescript fan.