Comment by jnxx | Hacker News Reader

Comment by jnxx | Hacker News Reader

Parent Full thread

> What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user.

None. In fact, Rust software will typically include larger and more frequent downloads for bug fixes, upgrades, and security fixes. The reason for that is that C programs, like vim, can fix bugs and security issues by updating individual dynamic libraries, which are likely to be part of the system. Rust programs can't, because they are statically linked, and this means the whole program needs to be downloaded and installed again. Also, Rust makes it much easier to manage and include library dependencies, which has the consequence that Rust programs in the long run will have an exponentially larger and deeper tree of dependencies, which means that fixes which are needed to fix some bug in a library will be more frequent. This is an effect which can be observed well for other languages like Python or Javascript with npm libraries.

That is probably fine for a web browser (which you basically need to re-install every other week anyways, and which uses auto-update for that), and might not have too much impact for a small tool, but once a program accumulates a large set of functionality and complexity (and therefore has more dependencies) let's say like Gimp, OpenOffice, VLC, or FileZilla, this is likely to become noticeable.

Another thing which might or might not be an issue is that software which is very fast-moving, and in rapid development, and adopts to breaking changes in its dependencies (as the Rust development model supports) is also a bit more likely to breaking changes in its own user interface, APIs and features. The reason for this is that with the included bundling of pinned library versions into the Rust executables, there is much less pressure to keep a stable API, as when software is composed of individual components which are used in many places with a strictly-defined API. This is actually not necessarily the case, it depends on what the software's authors promise (and keep) to its users. And breaking changes are very often an inconvenience for users; users and developers of software tend to have somewhat differnet opinions on how much friction and breakage is OK in order to get upgraded software.

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.

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

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

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

Reply on news.ycombinator.com