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

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

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.

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.