Hacker News new | comments | show | ask | jobs | submit login

I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful.

I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft. Unfortunately D jumped on the GC train and had other serious issues as well, allowing C++ to survive that attempt without a scratch.

Rust finally did the right thing, aiming for the same zero overhead/you only pay for what you use design which made C++ such a success.

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.

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? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". 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?

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.

"Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion), but they should not be part of a platform agnostic programming language. 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 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.

For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.




You're jumping to conclusions needlessly.

Windows is a first-class platform for Rust. Windows is Firefox's most important platform, and Servo needs to demonstrate that opportunities for optimization that could be relevant to Gecko are applicable to browsers running on the Windows platform.

If Rust seems like it's less well-integrated into Windows than it is into Linux and OSX, it's because none of the Windows developers who keep complaining about Windows support seem to be willing to step up to the plate. I've made this same offer several times to self-proclaimed Windows devs on HN: if you want Rust to get better on Windows sooner, make it happen sooner. Until then, the Rust devteam will spend their resources finalizing the language itself, while the Linux and OSX and FreeBSD and Android/ARM contributors continue to provide better integration with their chosen platforms.

This is not hostility. Please help us. We know that Windows is important. We need experts.


To be fair, the gaps between linux, osx, freebsd, and android are like a creek to the oceanic gap between any of them and windows support that most C++ windows devs I know (who are largely professional game devs) will consider useful. You aren't asking them to tweak a few things here and there to make a build go, you're asking them to make it fit a completely different system. You may find a volunteer willing to make that happen, but I don't think telling them they're all lazy bums compared to that guy who manages the freebsd port is going to get them there.

I also really want to be clear, as someone who's a huge fan of rust (from a distance so far) and wants to see it succeed, those windows devs will never agree with you about it being first class so long as it requires mingw to build. I know it makes things a lot easier when porting, but if it doesn't play nice with VC++ they won't give it a second look.


  > You aren't asking them to tweak a few things here and 
  > there to make a build go, you're asking them to make it 
  > fit a completely different system.
Precisely. Given this, is it such a surprise that Rust was initially written to use MinGW on Windows rather than MSVC back when it was an understaffed two-man project?

I should also note that porting to MSVC is a blocker for 1.0. It'll get done, we're just not sure by whom yet. Tell your friends: http://careers.mozilla.org/en-US/position/o3VZWfwD


I admire what you're doing, but I find the assertion that Windows is a first-class Rust platform difficult to square with your repeated requests for more Windows volunteers to make that happen. Windows developers are everywhere. Why doesn't Mozilla hire some Windows experts for the Rust team?


Mozilla is continually hiring new people to work on Rust. They haven't yet hired any Windows experts because better Windows integration is merely a high priority, and not the highest priority (that would be stabilizing the design of the language itself).

If you know any Windows devs with the appropriate experience, it couldn't hurt to have them apply: http://careers.mozilla.org/en-US/position/o3VZWfwD


Agreed. The message from Mozilla is that "Windows is really important to us, please come do it". Meanwhile they're paying for the development of yet another Unix-style package manager.

Clearly there is a list of priorities that guide these investments, and Windows support doesn't rank very high on that list.


  > Meanwhile they're paying for the development of yet 
  > another Unix-style package manager.
A package manager that will be platform-independent, and thus benefit Windows devs as well. At Rust's current state it's hardly surprising that they've chosen to allocate resources to efforts that will benefit all platforms equally. Meanwhile, the community for every platform but Windows is chomping at the bit to submit improvements. No doubt they're still holding out for the Windows community to do the same, without having to resort to hiring a dev specifically for Windows. But it will happen, if it has to.

In the meantime, if you know any experienced Windows devs looking for jobs working on Rust, please point them towards http://careers.mozilla.org/en-US/position/o3VZWfwD


You should really put more effort to get Rust work smooth on Windows withouth counting on volunteers.

Think of MySQL vs Postgres adoption. I belive that at the certain moment the primary reason that all Apache/PHP stack devs were choosing MySQL over Postgres was that MySQL was very easy installable on Windows (all these LAMP/WAMP packages that were creating ready-to-use dev environoment).


> 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.


> Rust was still in heavy development

That time is (still) now.

(E.g. four weeks ago was the week in which the most pull requests have been merged ever (89).)


>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).


> 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.

So? C also doesn't have a module system. It doesn't mean it's not a desirable feature.

> "Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion)

Package managers and UX are orthogonal concepts. You're free to not like Linux package managers, but the development of nuget in Visual Studio shows that not everybody embraces the installer download "package management" with enthusiasm. You'll note that most modern (and not so modern) programming languages (Java, Python, Perl, Ruby, Haskell, PHP...) have found the need for one.


Forgive me if I'm wrong but isn't the Nuget package manager becoming increasing more popular on .Net / Windows environments?

I've used Node extensively on Linux but working with Node + Windows (with the NPM package manager) in the last few months has been pretty smooth too.

I fail to understand why you think package managers are a Linux-only phenomenon.


You are correct, it would be hard to live without NuGet when writing .NET applications.

The parent is really full of it. Having written several large C++ applications on Windows, a package manager would of been incredibly useful. Having to track down native dependencies and manage platforms/architectures is incredibly difficult and annoying without one.

If you write major C++ applications and do not desire a package manager either you have serious NiH syndrome and write everything yourself or just like wasting time.


been writing .net apps for ten years and still don't use nuget.


>Isn't the Nuget package manager becoming increasing more popular on .Net / Windows environments?

I do not know how popular it is exactly (how can you?), but I am willing to bet money on the fact that the vast majority of Windows developers do not use it.


A large part of the linux|mac centering of the current development is that the lack of contributions from Windows developers. It's an open source project, and while we make sure it works on windows, more feedback and contribution from "Windows natives" would be fantastic.

I have never programmed on Windows, and wouldn't be able to gain the experience needed in time for a Rust 1.0 launch. Join the mailing list and IRC channel and offer feedback, if not patches!


Most games are on iOS and android, not windows.

Firefox, and Mozilla, the biggest users of rust are windows developers, and multiplatform C++ developers.

C++ has no packages, and making multiplatform code in C++ is hard. Very little code is reusable, especially outside of the platform in which it came in.

"For the sake of games no longer crashing randomly because of memory corruption bugs: change course now." You realise, this is one of the main design goals of rust?

Lots of people in the ruby, python, and node worlds use package managers on windows. Besides, windows is C#, and moving heavily towards tools such as node.js, and other multiplatform tools.


I think the fact that Windows devs are getting itchy to have full support is a good sign. It means that the language is becoming popular.

That said, I'd like to point out that the same thing happens all the time with languages developed in Windows land. I happen to really like F#, but Linux support for the language compared to Windows support has historically been relatively poor. It was only the heroic volunteer efforts of the mono devs that brought a respectable degree of support for F# to Linux.

And like mono, Rust is an open source project. Consider pitching in and helping build the Rust you want if you know how, or else consider learning how to do so if you don't.

I do happen to agree that package manager support should probably not be a priority at this stage. I think all available manpower and funds should be used to get the language to 1.0 as fast as possible. People won't put up with massive amounts of breaking changes forever.


> Every language which needs a "package manager" tends to make building standalone applications painful.

Huh? Python has a (sort of) package manager and you can still make a standalone application by bundling every dependency. You are very certainly mistaking the OS-level package manager (used primarily for installing applications) from the language-level package manager (used primarily for building applications). Once you have built a standalone binary, the job of the language-level package manager is done.

> 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.

I regularly use Rust (nightly) in Windows. Windows support is problematic since it differs from every other major platform, but it did not have a serious problem that seriously discourages the Windows platform. (Not to mention that I regularly build a standalone binary for Windows!) I admit it is not in the best state, but it should be improved and is being improved.

> 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? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". 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?

As a multiplatform guy the introduction of package manager actually marks the divorce with the strong Unix assumption, since Rust has actively avoided the platform-dependent tools so much that it now does not require the C compiler at all (!) and the only remaining platform-dependent tool was the Make. This is now about to change.

> 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.

That's why SQLite ships with an amalgamated source code, a sort of unfortunate thing. Dependency problem is so bad in C/C++ that most developers gave up and grew the half-baked solutions, which have another share of problems.


>Huh? Python has a (sort of) package manager and you can still make a standalone application

You can (try) yes. Have you tried it? I have. It was a horrible experience. Support for making standalone binaries is an afterthought in the Python world. It is usually not a simple process that "just works" (on Windows in particular).

>I regularly use Rust (nightly) in Windows

I know a guy who managed to write a game in Ruby and somehow turned the code into standalone Windows binaries. I know that Rust can be used on Windows, that you can use it to build standalone binaries, that is not the point. The point is how well, idiomatically, and smoothly that works.

>Windows support is problematic since it differs from every other major platform

If you do not consider consoles or embedded systems major platforms that is. Most of the world is not POSIX.

>does not require the C compiler at all

The last time I tried to use Rust on Windows it required a particular version of MinGW.

>Dependency problem is so bad in C/C++

I have used C and C++ for a long time, and I cannot say that dependency hell was ever a problem. One of the many things wrong with the "package manager" paradigm is that it encourages people to write software which is a tangled web of dependencies. Software should have few third-party dependencies, that makes maintenance and porting a lot easier. Witness the recent Python 2 -> 3 drama. The primary reason why people did not, could not upgrade to Python 3 was because they had to wait for all the dependencies of their apps to be ported. Many are still waiting.


> I have used C and C++ for a long time, and I cannot say that dependency hell was ever a problem. One of the many things wrong with the "package manager" paradigm is that it encourages people to write software which is a tangled web of dependencies. Software should have few third-party dependencies, that makes maintenance and porting a lot easier.

I think that's a terrific case of "that's my use case and therefore it should be everybody else's too". Try writing a complex web business application with "few third party dependencies" while not reinventing the wheel at the same time. There are many cases where having many third-party dependencies is necessary and the right thing to do, because your customer is emphatically not paying you for writing a web framework, a REST routing layer, an ORM, a full-text indexing system, a logging system and an AMQP client. Attempting to sweep the problem under the carpet by saying "just don't have dependencies" is silly. The only thing to do is to design a dependency system that works.


You write much software like that in C or C++? The sector you mentioned is dominated by other languages (Ruby, JavaScript, Java) for a reason.

You are right that my statement was too generalized, though. Yes, there are sectors where the "gluing together lots of libraries" style is the most practical one and "few third party dependencies" is not practical. However, there are already languages for that, and nobody is waiting for Rust to replace Ruby.


After starting to write a small llvm-based language in C++ (before going back to Haskell), I had already dependencies on LLVM, xdg-basedir, log4cxx and doxygen in my build system. I was using the system libraries, and thinking all the time that it was good this was only a side project, because it was really a terrible way of managing dependencies.

As for Rust replacing Ruby, why not? It is a general-purpose language, it eschews a lot of the C/C++ verbosity, lack of memory safety and weak typing which make them such a pain. I could see it easily as a strong contender in the web platform department once it matures.


> nobody is waiting for Rust to replace Ruby.

There are a bunch of us Rubyists in Rust-land, actually. My "Rust for Rubyists" was one of the biggest early community tutorials. And a Rust extension to Ruby in Tilde's Skylight product is the third production deployment of Rust ever.

Rust will not exactly 'replace' Ruby for me for a while, but I can see a day where that's true.


> The sector you mentioned is dominated by other languages (Ruby, JavaScript, Java) for a reason.

Presumably there's a significant amount of software that both is library-heavy and would benefit from being faster-than-Java, enough so to make some extra memory management worthwhile? If the reason that such software is getting written in Java etc. instead is because dependency management is too unpleasant in C++, well then that right there is the case for something C++-like but with good dependency management.


> Have you tried it? I have. It was a horrible experience. Support for making standalone binaries is an afterthought in the Python world. It is usually not a simple process that "just works" (on Windows in particular). > I know a guy who managed to write a game in Ruby and somehow turned the code into standalone Windows binaries. I know that Rust can be used on Windows, that you can use it to build standalone binaries, that is not the point. The point is how well, idiomatically, and smoothly that works.

I've done it many times, and it is not quite bad to do that (it can even give a single executable file at some initial slowdown). In fact, it is so impressive that the non-compiled implementation can make a working and portable executable file at all. Rust is primarily a (ahead-of-time) compiled language and it would take a single command `rustc foo.rs` (or possibly `rustc -L<deps> foo.rs`?) to produce an executable file `foo.exe`. [1]

[1] Assuming you haven't used 0.9 and later versions, it now produces a statically linked binary by default. No `libblahblabla.dll` around.

> If you do not consider consoles or embedded systems major platforms that is. Most of the world is not POSIX.

It really depends on the definition (and I'm not saying POSIX is not the most widely available platform), but mobiles alone (approx. 300 million units sold) give a significant portion of POSIX systems.

> The last time I tried to use Rust on Windows it required a particular version of MinGW.

You haven't used 0.9, right? That restriction was temporary and it has now lifted. I think you still need MinGW for linkers right now though.

> I have used C and C++ for a long time, and I cannot say that dependency hell was ever a problem. One of the many things wrong with the "package manager" paradigm is that it encourages people to write software which is a tangled web of dependencies. Software should have few third-party dependencies, that makes maintenance and porting a lot easier. Witness the recent Python 2 -> 3 drama. The primary reason why people did not, could not upgrade to Python 3 was because they had to wait for all the dependencies of their apps to be ported. Many are still waiting.

Python 3 is a bad choice in my opinion as it hasn't learned from the precedent of Perl 6 "failure" (this was finally resolved when Perl 5 development has been restarted). But that does not justify the C/C++'s lack of package system: there are lots of old and faulty C/C++ codes around due to the lack of recent C99 or C11 or C++11 compilers at the disposal even without the package system.


> Python 3 is a bad choice in my opinion as it hasn't learned from the precedent of Perl 6 "failure" (this was finally resolved when Perl 5 development has been restarted).

I think they suffer from opposite issues. Perl 6's problem is that it was way too ambitious for the manpower behind it, and it turned into the Duke Nukem Forever of programming languages. The issue with Python 3 was that it introduced breaking changes, but was widely felt not to bring enough to the table to warrant these changes.


Dividing the language is bad in general, since it essentially divides the ecosystem behind them. In the case of Perl 6 the ecosystem couldn't control the ambitious development goal; in the case of Python 3 the ecosystem could control that but could not realize that the smooth transition plan is still a transition. There are less problematic but similar causes in other languages, PHP 4 vs. PHP 5 vs. PHP 5.3 (oops!), D 1.0 vs. D 2.0 and so on.


If you're doing static linking, it seems extremely trivial to get from "have a package manager" to "have a compiled binary that stands alone".

Pull the source down, compile/link it and you're good. App A and B can run with different versions of libfoo, because they're statically linked so you're good to go if slightly wasteful of code footprint. If you're expecting to do runtime dependency lookup by dynamically fetching things through the package manager, then I agree, you're gonna have a bad time.


    "One of the many things wrong with the "package manager" 
    paradigm is that it encourages people to write software 
    which is a tangled web of dependencies. Software should 
    have few third-party dependencies, that makes maintenance 
    and porting a lot easier."
Or it means that you can share the fruits of your porting with others.

If you and I work on a project that depends on module foo, only one of us needs to port foo to platform bar once for both of us (and everyone else) to gain compatibility with platform bar with respect to our dependencies.

What you want instead is a way to have package managers support defining cross platform modules so that bar doesn't have to be forked and published as an entirely separate module.

    "The primary reason why people did not, could not upgrade to 
    Python 3 was because they had to wait for all the dependencies 
    of their apps to be ported. Many are still waiting."
Then the problem is a lack of tooling to aid with porting the code to the new platform. Creating a tool that parses code into an AST and analyzes the code to help define how it can be made compatible with the future version of a language should be a tractable problem for 1-2 developers.

At the end of the day package managers are first and foremost social software whose role is to aid meatware in achieving eventual consistency. We've only begun to scratch the surface of what is possible in this respect.


On the flipside the lack of a standard package manager and various problems with libraries in c and c++ cause people to re-invent the wheel all too frequently.


    "If you do not consider consoles or embedded systems major 
    platforms that is. Most of the world is not POSIX."
Would you even use a package manager on an embedded system? I would imagine that a package manager is far more appropriate for development systems and systems capable of being used for development. An embedded system would probably use a much simpler install system like what is used in TinyCore linux, if not even simpler than that. In fact, I would expect the package management on an embedded system to be driven by another system, which may be POSIX compliant. That software that puts code on that embedded system or console could be an extension to an existing package manager.

The biggest issue with most package managers AFAICT is that most aren't designed first as a platform with a programmatic interface. At the end of the day, the CLI for a package manager should be just one of the clients driving the package manager.


A package manager like this is intended for development time. Since you don't actually do your development on the embedded system, you can still use it fine.

You'd generate some build artifact with the help of Cargo, and that's what you'd load onto your device.


The python comparison isn't really good here. Rust is a compiled language and usually statically links in stuff (which makes total sense for libraries that are neither system libraries nor handled by a package manager, when you only deliver one binary)


Software has dependencies. If Rust's attitude were "software shouldn't have dependencies", it'd simply be trying to wish away a problem. Rust should solve the dependency problem instead of pretending it doesn't exist.


You said that they are trying to eliminate the dependency on make. Please please please tell me that they are considering something designed like tup instead:

http://gittup.org/tup/

Given how long it takes to build rust, I would hope a faster build system is a priority. Running `brew install rust` is bar none the longest build process I've seen in the brew ecosystem.


That's not a problem of the build system, but rather a fully bootstrapping compiler (needs to compile itself 3 times), that's doing certain things in rather non-optimal ways (e.g. passing more code than necessary to the optimiser (LLVM)).


Are you building HEAD? The bottled 0.9 install is quite quick.


> I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft.

Lack of decent package management is part of that cruft. As someone else pointed out, you're definitely confusing this with system package management. A good package manager for Rust could make it much much easier to have good Windows support, because it could Windows-specific compilation and packaging problems in one place, rather than relying on each individual library author to solve them. There is no reason it couldn't interact nicely with Visual Studio, unless that is not something Visual Studio is interested in doing.

This could be a really good thing for your apparent interest in Rust, but you're looking at it through the narrow lens of your past frustrations, rather than thinking about and advocating for ways it could alleviate them.


I hate package managers too, but the worst I've ever seen were proprietary "solutions" in the games industry which did do awful tricks to make VS play ball.

It is no exaggeration to say people would avoid updating packages in their projects (i.e. the whole point of using a package manager was nullified) since they knew they would lose days or weeks merely getting back to where they were.

The problems with package management seem to be exponentially proportional to how clever the person implementing the system thought they were. Any more than a declarative list of dependencies per package that can be fully evaluated to a programmer readable dependency tree prior to a single package update and you've created a self sustaining beast that will consume more of your time than developing the actual product.


Node works very well under windows, including a great package manager - npm. It can be done.


"'Package managers' are a Linux-ism..."

I personally have much the same reaction to language-specific package managers as you do. But my question is a little different: how is the Rust package manager going to interact with the Linux distribution's package manager?

If the answer starts with "Well, you build your own installation of the language..." (Hi, Haskell!) I am afraid I may start to cry uncontrollably.


> Also remember that C++ does not have a "package manager"

Many large, truly cross-platform, continuously-integrated C++ applications do - out of necessity - have an (ad-hoc, underspecified) approximation of a package manager. CMake-based projects come to mind immediately with the "build the world" approach using CMake external projects. GYP for chromium is the same.


How do you deal with dependencies in Windows-land? Do they wind up all getting embedded in the Visual Studio project? How do you deal with projects with different build systems? Or are Visual studio projects basically the package management in the ecosystem?

On linux I've basically wound up depending on the distribution packages, but this varies from distro to distro. The other option is embedding a build of all dependencies into the project, but this is slow, painful, and prone to error. Having a neutral package manager for C and C++ would be amazingly useful for this (though it would have actually be used. We use some python packages but some of them don't work when installed via pip so it's back to depending on the distro package).


> 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.


> Because we have a feature that you don't have to use to use the language or libraries, Rust is dead to you?

This is especially frightening as they use C++ and therefore must be using EVERY C++ feature that exists.


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.


All of your posts have been full of strawmen and mischaracterisations... (e.g. the insanity about only Linux being supported.)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: