Hacker News Reader

  > Wasn't this release supposed to finally offer a Windows 
  > package which works out-of-the-box?

Nope! No idea where you got that impression.

  > Who is in charge of the Windows port?

We keep asking for people knowledgeable about Windows to step forward and lead the effort to port us off MinGW and onto MSVC, and none ever have. Would you like to volunteer? :)

To clarify, the goal is to be using the native Windows toolchain by 1.0, if at all feasible. Servo has to work on Windows, after all.

I think using LLVM's native tool chain will end up being more feasible, fwiw.

Indeed, I'd love if LLD somehow matured in time for Rust 1.0. But I have no idea what their timeframe is.

Please don't depend on MSVC. Why not simply bundle the needed MinGW parts?

Please don't depend on MinGW. MSVC is the best supported compiler toolchain on Windows. Use it.

It's also horrible, but Arelius is right, it's the best option.

What's so horrible about it?

It's a very mature toolchain, and has better modern (C++11) support than the version of G++ on my Linux box.

The Express version restricts distribution of the binaries created with it IIRC. Also it's quite a heavy download compared to MinGW.

Please keep in mind that I'm not comparing writing C++ programs with MinGW vs. VC++. Rust just needs a linker for some tasks, which should be lightweight.

No one is suggesting that it should be the exclusive supported toolchain.

It may strictly be a larger download than MinGW, but it's certainly less painful and confusing. Sure, Rust may just need a linker, but MinGW is anything but lightweight.

It sure is the best option for C++ Windows development, but not for Rust to depend on and use.

But having to install the entire mingw toolchain is also clearly not the best for Rust to depend on and use.

I just started looking at Rust and like what I see so far. I may be able to help; I worked on the Windows port of Go and put together the MinGW build environments as well as the binary installers.

If someone can point me to a list of outstanding issues/requirements and a contact person it'd be much appreciated. Note, I've already found this https://github.com/mozilla/rust/issues/8996 and this https://github.com/mozilla/rust/issues/1237.

I'm assuming the workflow notes at https://github.com/mozilla/rust/wiki/Notes are up to date?

I personally don't know what's necessary now, but if you feel like joining #rust or #rust-internals on irc.mozilla.org (which I recommend :) ), then vadimcn and klutzy are the people to talk to. (IRC handles match their GitHub names.)

...doing it now.

Installing Go on windows was a breeze.. thanks =)

Thanks for offering! I'd suggest that you make a post to the mailing list for maximum visibility:

https://mail.mozilla.org/listinfo/rust-dev

HN comments and IRC chats tend to get lost in the shuffle without always attracting the attention of the devs.

I'd love to help with this, but I'm under the impression that this would also require getting llvm working properly under msvc, which just sounds like an immense task.

What about packing the required libraries in the installer, instead of forcing everyone to play Lego with versions, as starting point?

Perhaps part of the problem is perception.

When people download an exe installer on Windows, they generally expect it to install something that works out of the box.

Please note that I am not saying it should be expected that there is a one-click (or double- as it were) solution for Windows at this point, I am just saying that people might ge t that impression from the download link on the front page, and the fact that it is an exe installer.

Perhaps if you put it in a zip -- I am sure the people who can find and follow the notes for installing the rest of what is required can handle zip.

Just noticed that pressing the exe download link on the front page actually takes you to the wiki entry now, that's helpful.

Thanks for your report. I understand your frustration, and it's true that Windows support continues to lag. Some of the mingw dependencies were eliminated this release but not all. In particular, Rust still depends on mingw's linker. This is a major concern and Rust 1.0 will not be released without a self-contained toolchain on Windows.

>Wasn't this release supposed to finally offer a Windows package which works out-of-the-box?

Nope.

>I just tried it. Only got an error message about a missing GCC component. Seriously, a ~90MB download and that still does not include all the GCC dependencies?

Seriously, an early adopter that can't handle GCC dependencies?

>Who is in charge of the Windows port?

YOU are, it's open to the community.

That's the kind of attitude that will ensure that Rust does not see truly widespread adoption. Windows is, like it or not, still a very significant platform today. Poor Windows support will hurt the adoption of Rust. It shouldn't be up to some vague "community" to seamlessly support Windows. That's something that the core Rust developers should work to offer.

Agree 100%. Gaming, for example, is one area where Rust can/will shine, and Windows is very important there.

The core team is working on the language for now, I imagine once the few remaining core features start to stabilise they will be able to shift their focus to things like libraries, tooling and platform support.

Also, Windows support is definitely a priority: every single proposed patch is tested on Windows (as well as Linux, OSX and one of the BSDs, and soon, Android), and any failures cause a rejection.

Don't assume that a dismissive comment from some random person on HN is indicative of the Rust team's attitudes.

>Windows is, like it or not, still a very significant platform today.

I agree.

>Poor Windows support will hurt the adoption of Rust.

I agree again.

Where I disagree is that there's any serious hurry for "it just works" Windows support to exist now, when the language is in flux, the core team has tons of other priorities (like, finalizing the design and creating stuff), and we're several releases away from 1.0.

Where I disagree is that people that try to early adopt a compiler and toolchain at pre-beta stage, have a right to whine about it and demand stuff, or even get to blame developers ("who is responsible for the Windows port?").

Where I disagree with is with entitlement.

>* It shouldn't be up to some vague "community" to seamlessly support Windows. That's something that the core Rust developers should work to offer.*

That's what I disagree with.

The core team has schedules, finite time and priorities. And could even be way over their head with some stuff, like finalising some language semantics.

That some other developers are saddled with a non-UNIX/POSIX OS, doesn't mean the core team must automatically bend over and prioritize them over other stuff. Even if it "hurt Rust adoption".

You know what will hurt Rust adoption more? Spending resources to port a half-finished compiler to various systems, instead of getting it done first.

[NOTE: In no way do I speak FOR the core team or are affiliated with it (other than playing with Rust since 0.3 days as a user). I just wanted to respond to this particular attitude].

On Windows, I use Scoop http://scoop.sh/ (vaguely similar to homebrew on OSX). There's a Rust package which will install all the dependencies for you. It hasn't been bumped to 0.9 yet, but I assume that'll happen soon.

Just tried Scoop - very useful especially the sudo for Windows.

Well there is always runas

Yep, Scoop has Rust 0.9 now.

Thanks for sharing, I didn't knew it.

You should be able to use any [reasonably recent] MinGW environment with 0.9. Is this not the case?

[edit] You do need to install gcc in your MinGW, though.

I do not know, but if I recall correctly there was an issue with 0.8 where the - then current - MinGW installer would grab packages incompatible with the Rust 0.8 binaries so you first had to setup the current version of MinGW, and then use MinGW's own package manager to rollback to a version compatible with the Rust build.

This had been fixed since. You should be able to use mingw without rolling back anything.

This has been my experience as well, even after trying to follow a few guides.