> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
This is not correct. Mac OSX is very much a first class platform supported as well as (or better than) Linux, and the "wait until the language is stable" is not the attitude that is being taken: firstly, every single changeset is required to pass tests on Windows to be merged (i.e. Windows is being regarded as first class too, even if there's a few lacking areas), and secondly, people are working on it, although slowly, such as the removal of the dependency on GCC's C++ runtime.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I don't see this changing particularly. AIUI, cargo is more designed to be a (pluggable) dependency manager, exposing as much of its internals as possible (via CLIs, i.e. callable binaries) so that external tooling can hook into it in a sane way.
>every single changeset is required to pass tests on Windows
That alone does not make Windows a first class platform, and the attitude I quoted was exactly what I got from the developers when I pointed out how relatively complex it was to get Rust working on Windows. Note the past tense, that boat has sailed, while Rust was still in heavy development you needed some serious dedication or an uncommon skill set just to build Hello World on Windows.
Click on setup.exe, wait for the installer to finish, click on "Rust command prompt" - that is how it should have worked. That is what first class support for Windows during development would have looked like, not fiddling around with ports of Linux tools.
>Click on setup.exe, wait for the installer to finish, click on "Rust command prompt"
You're wanting things that don't even exist in Linux land. We still have a multiple stage build process that can take hours (depending on your available processing power). If any pre-built Linux binaries are available from a trusted source, I couldn't find them.
The bottom line is, if you're horribly offended by Rust's lack of Windows support, and want to use the language, then pitch in and lend a hand. That's what people who want more embedded ("bare metal") support are doing (myself included, although I haven't yet open sourced my improvements).
After some initial stumbling blocks because of the pointer semantics, I've started using Rust regularly and it's becoming a very nice language. And it's the only new non-research language right now that actually has fast, deterministic performance ideal for real-time applications and games (Nimrod is close for soft real-time).
This is not correct. Mac OSX is very much a first class platform supported as well as (or better than) Linux, and the "wait until the language is stable" is not the attitude that is being taken: firstly, every single changeset is required to pass tests on Windows to be merged (i.e. Windows is being regarded as first class too, even if there's a few lacking areas), and secondly, people are working on it, although slowly, such as the removal of the dependency on GCC's C++ runtime.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I don't see this changing particularly. AIUI, cargo is more designed to be a (pluggable) dependency manager, exposing as much of its internals as possible (via CLIs, i.e. callable binaries) so that external tooling can hook into it in a sane way.