> I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful.
Rust does not need a package manager. We've used it for a long time without one. If the package-manager-free workflow with manual installation (or through an IDE, etc.) is to your liking, use it!
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform.
Totally false. 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.
Graydon was adamant that Windows must be supported from the start, and we have not changed that.
> 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.
What feedback is that? Most of the language-level concerns are platform-independent, except for COM, etc (which we are familiar with).
Furthermore, we have Windows support, and it's not that far behind the other platforms. Later on in your comments, you talk about a binary installer. That's not something we have on any platform yet.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns?
You don't need to use it if you're using Visual Studio. If you like your tools, keep them! That's Rust's attitude.
> I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Of course I would, if they were competent developers.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
> 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.
That is precisely what Rust does.
> Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
That is also precisely what Rust does.
> I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
This is really silly and hyperbolic, and somewhat insulting to those of us who have spent a lot of time making sure the design works well on Windows. Like I said, I've been working full-time on this project longer than anyone else and I exclusively use a Mac.
Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons. We have a lot of Windows developers here too, you know.
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.
> For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
To what? Abandoning the package manager? That'd be alienating a large segment of users who want a tool to create and share libraries, and deploy binaries onto servers for the sake of unhappy Windows developers who dislike that workflow. Instead I think we should do what we're doing now: invest in the package manager, but allow the tools and libraries to be totally independent of it, so that you can use Visual Studio or whatever you'd like with Rust.
>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.
Rust does not need a package manager. We've used it for a long time without one. If the package-manager-free workflow with manual installation (or through an IDE, etc.) is to your liking, use it!
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform.
Totally false. 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.
Graydon was adamant that Windows must be supported from the start, and we have not changed that.
> 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.
What feedback is that? Most of the language-level concerns are platform-independent, except for COM, etc (which we are familiar with).
Furthermore, we have Windows support, and it's not that far behind the other platforms. Later on in your comments, you talk about a binary installer. That's not something we have on any platform yet.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns?
You don't need to use it if you're using Visual Studio. If you like your tools, keep them! That's Rust's attitude.
> I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Of course I would, if they were competent developers.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
> 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.
That is precisely what Rust does.
> Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
That is also precisely what Rust does.
> I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
This is really silly and hyperbolic, and somewhat insulting to those of us who have spent a lot of time making sure the design works well on Windows. Like I said, I've been working full-time on this project longer than anyone else and I exclusively use a Mac.
Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons. We have a lot of Windows developers here too, you know.
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.
> For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
To what? Abandoning the package manager? That'd be alienating a large segment of users who want a tool to create and share libraries, and deploy binaries onto servers for the sake of unhappy Windows developers who dislike that workflow. Instead I think we should do what we're doing now: invest in the package manager, but allow the tools and libraries to be totally independent of it, so that you can use Visual Studio or whatever you'd like with Rust.