What's the advantage of writing an editor like this in Rust? And by advantage, I mean an advantage for me, the end user.
I'm quite pleased with neovim and I'm not planning on switching any time soon, so I guess I'm not the target audience for this tool. Then again, who is?
I don't think it makes a differences that it is written in Rust in the same way it does not really matter that Neovim has a cleaner codebase than Vim's in your everyday use of Neovim.
But maybe it will attract Rust devs who are also Vim users in the same Neovim attracted people who are versed in Lua ?
I have been using Vim for a while and learned a lot but I hate to have to configure it and the out of the box experience is really missing much. I don't want to have to have to manage something as basic as my text editor.
I want a battery-included modal terminal editor that has (mostly) Vim commands and is easy to use.
Onivim2 is fast and beautiful but it's a gui and it is not finished.
Kakoune looks great but I don't want to learn another set of commands as I might to have to use Vim again and don't want to "lose" my habits.
I recently learned of nvcode: https://github.com/ChristianChiarulli/nvcode. I haven’t tried it yet, but it’s another option in the pre-configured vim space that you might find interesting.
> 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.
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.
> 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.
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):
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.
It could potentially be easy to compile it together with all your extensions and configs into a single executable you can then just download on your servers/containers/whatever. I would definitely try it out (if I wasn't an Emacs user :)
I'm quite pleased with neovim and I'm not planning on switching any time soon, so I guess I'm not the target audience for this tool. Then again, who is?