[joelellis]

I heavily disagree with most of this comment. Static linking verses dynamic linking is a trade-off, and despite the shared bandwidth disadvantage and the difficulty of replacing the dependencies of a statically-compiled binary, there are a lot of advantages - primary of which is ease of distribution. Because the binary is mostly self-contained, it's far easier to install, can work in more environments and less likely to break as time passes and the systems around it change. These advantages greatly outweigh the disadvantages when developing g the program, for self-explanatory reasons, but also when distributing it. Many developers in languages where dependencies aren't included within the built asset bundle them anyway when distributing them because of this.

In regards to your second point, I will point you to the oft-linked https://wiki.alopex.li/LetsBeRealAboutDependencies .

Finally, your third point. Although much of the ecosystem is changing at a rapid pace, core and major packages, the ones most directly depended on, have either made very strong commitments towards stability, have a proven track record of having few or no breaking changes or both. Additionally, due to the nature of the package manager (and static linking), it's very easy to freeze the churning sections of the ecosystem for your application, use the important dependencies and even patch bugs you're encountering.

Additionally, the fact that rust's ecosystem is advancing at a rapid pace means that, well, it's advancing at a rapid pace. Most packages are high-quality and useful, and many are hugely advanced from what other languages have to offer, like the serde and regex crates. This reflects on the applications built with these libraries - you're probably heard of ripgrep, originally built almost purely to test the regex crate, or JQL, built on serde_json. There are many more amazing crates than I could possibly mention, and many more software projects like OneSignal's notification systems that showcase the amazing way the projects in the Rust ecosystem have been put together.

In short, most of the downsides that you mentioned are really mostly positives, and these positives do affect the applications a lot. Rust does have negatives, but it has plenty of positives, all of which have very concrete effects.

This is a bit of a wall of text, but your first paragraph irked me. Also, Gimp, OpenOffice and VLC are already huge. I don't use FileZilla, but I would expect similar.

[jnxx]

> Because the binary is mostly self-contained, it's far easier to install, can work in more environments and less likely to break as time passes and the systems around it change.

That can't be the whole story, otherwise we would not have operating systems, or at least, we would not have anything more than a kernel with nothing on top. There are good reasons for software to be a part of a common system, for example when you want components of the software to integrate and communicate with each other. For example, you probably do not want to log-in to each app again with the same user name.

This is different from a web browser, which, in a way, is an operating system and a platform, and requires relatively little integration with the surrounding system (in these times, often not even a PDF reader). But as a consequence, you have something which is called "inner platform effect", and I think there are few places where this term is more appropriate than in web browsers..

[jnxx]

> Additionally, due to the nature of the package manager (and static linking), it's very easy to freeze the churning sections of the ecosystem for your application, use the important dependencies and even patch bugs you're encountering.

Bug fixes are rarely back-ported, and if one wants to use new features, it is all too common to force an upgrade onto an partially incompatible version. And it is an open secret that most software users to not like that. They do not like change because they pay most of the cost.

The right way to do this is to have instead long-term backwards-compatible, ultra-stable APIs, and do development on these. And one cannot say that this isn't possible - this is precisely what the Linux kernel does.

[jnxx]

> In regards to your second point, I will point you to the oft-linked https://wiki.alopex.li/LetsBeRealAboutDependencies .

This is not a convincing argument. Rather, it confirms that there is a general problem: As its first example, the post points out an exemplary C++ program, RViz, that has 36 direct dependencies, and 133 total dynamic dependencies. The second example, VLC, has 495 dependencies.

Yes, it is written in C++. Does this prove that a high number of dependencies is not a problem? No. For example, here is a list of security issues in VLC (and I do not think it is exhaustive):

https://www.cvedetails.com/vulnerability-list/vendor_id-5842...

One can bet that the number of general bugs is much higher since a security issue is just a special type of bug. So, do you want to download a new image of a rust-written VLC every time there is a bug or security issue discovered in one of the dependencies? Another regular browser update just for the video player? And another regular fat download for the Rust version of vim? Perhaps on program start?

What can be clearly observed is that in larger programs, the number of dependencies is growing more or less exponentially and that is becoming, or will become, very difficult to manage within the next few years.

This is a general tendency, and it is only going to get worse. Take kubernetes: https://lwn.net/Articles/835599/, as an example. Or tensorflow. This is clearly not sustainable.

And this causes complex problems. A very easy example is what happens if you have a program which depends on two libraries, which both in turn depends on a third library, but only allow for different versions. Vendoring or bundling into static libs is not going to solve that - the only solution is a strict adherence to backwards-compatible components.

Bundling everything as static compiled-in libraries is only going to make the problem worse. It sure makes it easier to produce a program at first, but it makes it more difficult to maintain it. But maintenance is most of a program's life cycle and work included.

And the fact is that the snowballing, exponentially rising number of dependencies also will dwarf completely the effect of Rust's better memory security as a language. If the result is very good, Rust might avoid 90% of security issues. So it might have one-tent of the number of errors in the first place, but this would not help in a near future where complex applications will have more than thousand or several thousands of dependencies. One-tenth of the number of serious bugs in VLC is still a large number, for something that handles untrusted input. This just is going to become unmanageable, if it isn't already. Making it easier to include dependencies is not the solution, and including dependencies as static libraries is not helpful for end-user systems.