[wbond]

I was impressed by the toolchain when I first peaked at Go because it was dead simple to get up and running on any platform, especially Windows.

For gcc you have to deal with MinGW. Isn't LLVM just now getting to the point where it can build native Windows applications?

This is one area where I hope Rust makes progress. MinGW/Msys2 is just kind of gross stuff to deal with.

[RayDonnelly]

Care to explain what's gross about MSYS2/MinGW-w64? I'm genuinely interested in making it less gross.

[infogulch]

Want to make it less gross? Make it completely go away.

Installation of Go or Python is just like any other Windows install. You download an installer.exe or .msi, run it, and you're done. Things compile or run immediately, and you don't have to start using a "special" terminal just for it to work.

My experience with MinGW is very different. Especially for dependent languages. "Step 1: Install MinGW" what does that even MEAN?:

"Ok, I ran this installer, and it brought up the MinGW Installation Manager. Is it done? What am I supposed to do here? Which one do I choose? How do you even select a package? What even ARE packages? OK, so I select something then go the Package menu and select Mark for Installation. It's not doing anything. Is it done now? Close window. Nope that didn't work. Open it back up. Oh, so after marking a package I have to go to the Installation menu and choose Apply Changes. ..."

This actually happened to someone I was trying to help over the phone. Heaven forbid they get lost in All Packages and get confused by the dozens of packages each with half a dozen versions and each with three different, non-descriptive "classes".

Installation needs to be braindead simple. During installation it should show a list of extra languages that can be installed, where you can't uncheck 'base' (with an "Advanced Options" button in the corner that opens up the standard installation manager instead). It should set up any environment variables, including PATH, (and including restarting explorer to refresh the env) and it shouldn't require the use of any terminal other than cmd.exe (despite it being terrible).

If you're installing something else entirely that depends on MinGW, their installer should be able to bundle the MinGW installer, and it should install without having to make any choices. It should detect if MinGW is already installed and install packages there instead, still completely automated.

Make it go away.

[RayDonnelly]

I was asking about "MSYS2/MinGW-w64".

You seem to be confusing mingw.org (http://www.mingw.org/wiki/getting_started) and MinGW-w64 (http://mingw-w64.sourceforge.net) and your rant seems entirely directed at mingw.org.

The software distribution I was asking the parent poster about is MSYS2 (http://msys2.github.io/ and http://sourceforge.net/projects/msys2/), do please come back with constructive criticism on that project if you are interested enough to investigate further.

[infogulch]

You're correct, my complaints were towards mingw.org, not MSYS2. My apologies for not reading carefully enough. I may actually take a look, thanks for directing me.

[RayDonnelly]

There was a recent discussion on Reddit where some MSYS2 users chimed in that which may cover some useful ground:

http://www.reddit.com/r/cpp/comments/2v6vlg/decission_which_...

[wbond]

Yes, I'd be happy to, but I'm not sure they are "solvable" issues, because they seem to be more of architectural mismatches.

Part of the issue with most software that uses MinGW is that it is written with posix-y operating system in mind. That is, operating systems that can very efficiently fork processes and quickly deal with many small files. Unfortunately, Windows does neither well. Process creation is slower, and NTFS is a very lock-happy filesystem.

Why do I consider this gross as a user? Things like Git that utilize msys are slow on Windows. As in, I notice the UI hanging. Things like autoconf are terribly slow on Windows due to all of the small processes that are created to detect the environment. Antivirus tools will lock files that are created and generally slow things down due to the nature of lots of quick-running processes creating and deleting small files.

These are just realities of most software written for non-Windows platforms. So whenever I see a program that requires MinGW, I'm always very hesitant to use it. The user experience tends to be terrible. I can still remember an issue trying to compile subversion on Windows using gcc and having it take well over an hour. Turns out with all of the processes being forked and temp files being created, the antivirus program was adding a delay to every command. After completely disabling antivirus it compiled in 15 minutes.

So, in one sense, this ins't a problem with MinGW or msys, but it typical of software that relies on it.

The other issues I have with them is that they don't integrate well with the native tools on Windows. For instance, Pageant is a good, graphical SSH agent on Windows. You have to mess around with environmental variables and plink and junk to get it so you don't have multiple formats of SSH keys on your machine. Trying to deal with SSH through bash and msys is not a user friendly experience. PuTTY is the gold standard of SSH clients on Windows.

Using msys/MinGW is like running X programs on OS X, Windows programs through Wine on Linux, or Java GUIs on any OS. It has enough strange warts and doesn't quite fit the feel of the rest of the OS.

That is where Go was awesome. I downloaded go and there were 3 exes on my machine. I ran "go.exe build source.go" and out popped an exe.

[RayDonnelly]

Thanks, sure, POSIX is a round hole and Windows a square peg, but I think that the excellent work done by Cygwin over the last few years has done a great deal to file down the edges of the Windows peg. MSYS2's hacks on top usually function ok.

With Git, I can clone very large projects almost as quickly with MSYS2 as I can ArchLinux. We did begin to port msysGit (the native, non-MSYS executable, yeah, go figure) to MSYS2 and found very little speed improvement so stopped since the msys2 version is much more functional and always up-to-date.

Using Autotools on MSYS2 isn't significantly slower than on GNU/Linux. You can try building any of the many Autotools based projects we provide to see this for yourself. Besides, for software which relies on Autotools for it's build system, there's no choice but to use it (outside of cross compilation).

That NTFS (and the Windows filesystem layer) isn't fast is independent of MSYS2 vs native Windows anyway.

An anti-virus will slow down all Windows tasks to an unusable crawl, just run your scan overnight and take care about what you click on. MSYS2 isn't hit worse than, say Visual Studio. Fundamentally MSYS2 is software distribution who's end product is native Windows applications aimed at the user. The POSIX stuff exists just helps us get there (this is why we don't provide X Windows; if you want that, use Cygwin), so for example using Qt Creator as supplied by MSYS2 should give an experience that's roughly the same as using Qt Creator supplied by the Qt Project (but much easier to maintain).

Apart from for installing and updating packages, you can avoid the MSYS2 console and just run programs in C:\msys64\mingw64\bin.

The security advantages we bring via shared packages (e.g. libraries) are very worthwhile.

> Trying to deal with SSH through bash and msys is not a user friendly experience. PuTTY is the gold standard of SSH clients on Windows.

Since on MSYS2, things are shared, your SSH keys are shared between all applications that use them in ~/.ssh, as you'd expect. I use mklink /D to unify my Windows User folder and my MSYS2 HOME folders (be careful not to use our un-installer if you do this though, if follows the symlink :-(). We do have putty but I haven't checked that it doesn't use %AppData% or worse, the Windows registry to store keys. If it does that's a bug we'll fix. To install putty:

$ pacman -S mingw-w64-x86_64-putty