>I'm the earliest developer still full-time on the Rust language (4+ years) and I was exclusively using Mac OS X from the beginning. If you look at Servo, Mac is actually better supported than Linux at the moment.
You mean XCode and the rest of Apple's developer tools have great Rust support? There are up to date Cocoa bindings?
That would be real Mac support.
I know that many Linux people switched to Mac OS X because it has this whole POSIX system underneath its chrome, which normal Mac users never touch, but which makes an adequate Linux replacement + you get the nice Mac desktop OS on top of that. But as I said I do not see how running ports of Linux tools on that layer qualifies as real Mac support.
>What feedback is that?
Different types of software get developed for Windows, trying to use Rust in these different scenarios might have exposed issues specific to said use cases. Demanding PC games are overwhelmingly developed on and for Windows for starters. And there is also the issue of "cultural incest". There are certain hegemonic attitudes among UNIX developers about how thinks should work, how they should be organized, named etc. Attitudes which are often not shared by other developer communities. However, the early development of C++ happened in a UNIX dominated environment too so maybe this will not be that problematic.
>you talk about a binary installer. That's not something we have on any platform yet.
The thing is, just dropping source tarballs on people is considered acceptable among UNIX developers, that is the way you do things there. But it is not the way you do things on Windows.
>Of course I would, if they were competent developers.
The issue is not technical competence, but "cultural competence" if you will. Building software people on platform X actually want to use, which requires respecting the cultural norms. You just gave a nice example of lacking cultural competence by assuming that not providing a binary installer which does not require manual twiddling is just as acceptable on Windows as on Linux, while it really sends a bad message on Windows and leads to Windows developers never bothering with Rust at all. It is like, nobody on Windows has a problem with closed source drivers .. but the Linux devs hate those.. bad culture fit. It matters, a lot.
>There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
apt-get is the Debian package manager, Homebrew is for UNIX devs using the POSIX layer of OS X, neither is a "C++ package manager". These pieces of software are OS specific tools and have no direct relation to the C++ programming language at all.
>That is also precisely what Rust does.
Well, that is great. However, I remain highly skeptical. I can already see the install instruction for Rust libraries on Github etc. "Cargo install foobar", no word about how to build the library without Cargo, the dependencies are only specified in Cargo metadata files etc. Plus as I said package managers encourage developers to write software with lots of dependencies .. which becomes a pain to build without said package manager. While in theory Cargo may be optional, I doubt it will be in practice. The whole Rust ecosystem will grow based on the assumption that everyone uses Cargo, and everyone who does not will be in for a world of pain. Other languages who have official package managers show this.
>Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons.
There is a big difference between being able to turn your particular code base into Windows binaries and actually providing a good development experience on Windows. The first does not necessarily require the second. I think most (all?) Mozilla devs use a UNIX-style development environment, even if Windows is the dominant target platform.
>First-class support for Windows is evident everywhere in the design, from the use of libuv instead of libevent for the green threading to the lack of exposure of `select` or `fork` due to that not performing well on Windows.
Again, I was mostly talking about the developer experience, not about the ability to somehow build fast binaries. That is expected too of course, but not enough for the "first class" label in my book.
>To what? Abandoning the package manager?
Yes. See above for the reasons why. When I build my C++ software on Linux I do not need a special "C++ package manager". I just apt-get the dependencies (e.g. SDL). Does Rust really need something more? As I said, I think a language specific package manager will undermine Rust's ability to be a general C++ replacement.
>and somewhat insulting
I did not mean to insult anyone. I want Rust to succeed, that is my only agenda here. I think you are on the wrong track with this and thus I wanted to warn you about it. Maybe I am completely wrong, we will see. I will not bother you again, because as a Windows game developer Rust is dead to me now.
Maybe I will look at it again once I read about the first major game written in Rust being released, which will probably be somewhere between 5 years from now and never. But right now my money is on never.
> You mean XCode and the rest of Apple's developer tools have great Rust support? There are up to date Cocoa bindings? That would be real Mac support.
Yes! In fact, I've given talks on using Xcode's Instruments.app with Rust! You get full support for Rust with it. There are also actual up-to-date Cocoa bindings, which Servo uses.
I have no idea where you have gotten the idea that Rust cares only about Linux.
> You just gave a nice example of lacking cultural competence by assuming that not providing a binary installer which does not require manual twiddling is just as acceptable on Windows as on Linux, while it really sends a bad message on Windows and leads to Windows developers never bothering with Rust at all. It is like, nobody on Windows has a problem with closed source drivers .. but the Linux devs hate those.. bad culture fit. It matters, a lot.
We aren't done with the language yet. There is no reason why we can't ship a binary installer.
> Well, that is great. However, I remain highly skeptical. I can already see the install instruction for Rust libraries on Github etc. "Cargo install foobar", no word about how to build the library without Cargo, the dependencies are only specified in Cargo metadata files etc.
Rust has the ability to build libraries without cargo. You can do it today. Cargo is a package manager, not a full-fledged build system.
When it comes to dependencies, note that Rust specifies dependency information in the crate itself, so it is independent of cargo. This is by design.
> Plus as I said package managers encourage developers to write software with lots of dependencies .. which becomes a pain to build without said package manager.
Software has dependencies. Our answer to dependencies cannot be "don't have dependencies", as you think it should be. That is trying to wish away a problem instead of solving it, and would be far worse for language adoption. Maybe as a Windows game developer that may be a scalable solution, but for server software (HTTP, routing), browsers (images, 2D rendering, font stuff), scientific software (LAPACK), it just isn't realistic.
> While in theory Cargo may be optional, I doubt it will be in practice. The whole Rust ecosystem will grow based on the assumption that everyone uses Cargo, and everyone who does not will be in for a world of pain. Other languages who have official package managers show this.
Most languages with package managers (really, most languages period) are languages that run on a VM and don't produce native binaries, so you're probably running them from the command line or using a language-specific IDE to begin with. Because of that, installing packages from the package manager is scarcely more effort than using the language to begin with, and so everyone uses the package manager. In a language in which a large portion of people are using Visual Studio and using the language package manager was too much of a hassle, I suspect library developers would not hardwire cargo into their libraries.
(Not that I think it's really possible to "hardwire cargo" or make a "world of pain" for users who don't use it. All cargo does is automate finding and installing libraries. You can always do it manually. cargo is an independent tool that does nothing but read metadata and invoke the Rust compiler; it is not integrated into the toolchain.)
> Yes. See above for the reasons why. When I build my C++ software on Linux I do not need a special "C++ package manager". I just apt-get the dependencies (e.g. SDL). Does Rust really need something more? As I said, I think a language specific package manager will undermine Rust's ability to be a general C++ replacement.
We can't rely on OS package managers to package Rust for a good developer experience.
* First of all, it's a chicken and egg problem: the OS package managers are slow to update, and they don't have much of a motivation to update without Rust uptake. But without a good package management system, Rust will have a hard time getting that uptake to begin with. Look at the situation now: Rust has been around for a while and OS package managers have little support for it. We have to take the situation into our own hands.
* Some OS package managers (most notably Homebrew) do not like language-specific packages as a matter of policy, other than for C and C++; they prefer that languages have their own package managers.
* Many developers prefer faster development than OS package managers allow for. We live in the age of GitHub, and the dead simple "push your libraries to a server for the world to use" has been extremely important for communities like Node.
* For servers, it's very important that your production machine be able to replicate the development environment precisely. This is why you need a system that can tie your software to the exact versions of your dependencies.
> I did not mean to insult anyone. I want Rust to succeed, that is my only agenda here. I think you are on the wrong track with this and thus I wanted to warn you about it. Maybe I am completely wrong, we will see. I will not bother you again, because as a Windows game developer Rust is dead to me now.
Because we have a feature that you don't have to use to use the language or libraries, Rust is dead to you? I have no idea how that makes any logical sense. Having a Rust package manager does not preclude good Visual Studio support.
> Maybe I will look at it again once I read about the first major game written in Rust being released, which will probably be somewhere between 5 years from now and never. But right now my money is on never.
We are not just targeting Windows game developers. If having features that you aren't going to use and don't have to use is going to be a blocker for adopting it, I think that's irrational, but I can't do anything about it.
So far most if not all of the games in Rust are using SDL as a layer over Direct3D, because they don't want to be Windows-only. That's a dependency right there. Fetching and installing the latest version of rust-sdl is a real pain, and having a way to automate that can only help adoption.
That post reminds me of a farm field: so many straw men.
I appreciate you perfecting it with accusing me of being illogical after constructing all of them. Your post does not deserve a detailed reply.
You mean XCode and the rest of Apple's developer tools have great Rust support? There are up to date Cocoa bindings? That would be real Mac support.
I know that many Linux people switched to Mac OS X because it has this whole POSIX system underneath its chrome, which normal Mac users never touch, but which makes an adequate Linux replacement + you get the nice Mac desktop OS on top of that. But as I said I do not see how running ports of Linux tools on that layer qualifies as real Mac support.
>What feedback is that?
Different types of software get developed for Windows, trying to use Rust in these different scenarios might have exposed issues specific to said use cases. Demanding PC games are overwhelmingly developed on and for Windows for starters. And there is also the issue of "cultural incest". There are certain hegemonic attitudes among UNIX developers about how thinks should work, how they should be organized, named etc. Attitudes which are often not shared by other developer communities. However, the early development of C++ happened in a UNIX dominated environment too so maybe this will not be that problematic.
>you talk about a binary installer. That's not something we have on any platform yet.
The thing is, just dropping source tarballs on people is considered acceptable among UNIX developers, that is the way you do things there. But it is not the way you do things on Windows.
>Of course I would, if they were competent developers.
The issue is not technical competence, but "cultural competence" if you will. Building software people on platform X actually want to use, which requires respecting the cultural norms. You just gave a nice example of lacking cultural competence by assuming that not providing a binary installer which does not require manual twiddling is just as acceptable on Windows as on Linux, while it really sends a bad message on Windows and leads to Windows developers never bothering with Rust at all. It is like, nobody on Windows has a problem with closed source drivers .. but the Linux devs hate those.. bad culture fit. It matters, a lot.
>There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
apt-get is the Debian package manager, Homebrew is for UNIX devs using the POSIX layer of OS X, neither is a "C++ package manager". These pieces of software are OS specific tools and have no direct relation to the C++ programming language at all.
>That is also precisely what Rust does.
Well, that is great. However, I remain highly skeptical. I can already see the install instruction for Rust libraries on Github etc. "Cargo install foobar", no word about how to build the library without Cargo, the dependencies are only specified in Cargo metadata files etc. Plus as I said package managers encourage developers to write software with lots of dependencies .. which becomes a pain to build without said package manager. While in theory Cargo may be optional, I doubt it will be in practice. The whole Rust ecosystem will grow based on the assumption that everyone uses Cargo, and everyone who does not will be in for a world of pain. Other languages who have official package managers show this.
>Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons.
There is a big difference between being able to turn your particular code base into Windows binaries and actually providing a good development experience on Windows. The first does not necessarily require the second. I think most (all?) Mozilla devs use a UNIX-style development environment, even if Windows is the dominant target platform.
>First-class support for Windows is evident everywhere in the design, from the use of libuv instead of libevent for the green threading to the lack of exposure of `select` or `fork` due to that not performing well on Windows.
Again, I was mostly talking about the developer experience, not about the ability to somehow build fast binaries. That is expected too of course, but not enough for the "first class" label in my book.
>To what? Abandoning the package manager?
Yes. See above for the reasons why. When I build my C++ software on Linux I do not need a special "C++ package manager". I just apt-get the dependencies (e.g. SDL). Does Rust really need something more? As I said, I think a language specific package manager will undermine Rust's ability to be a general C++ replacement.
>and somewhat insulting
I did not mean to insult anyone. I want Rust to succeed, that is my only agenda here. I think you are on the wrong track with this and thus I wanted to warn you about it. Maybe I am completely wrong, we will see. I will not bother you again, because as a Windows game developer Rust is dead to me now.
Maybe I will look at it again once I read about the first major game written in Rust being released, which will probably be somewhere between 5 years from now and never. But right now my money is on never.