Hello, Am 20.06.2020 um 06:52 schrieb Greg A. Woods:
These days a decent well supported, very capable, and much more widely available language like Go would seem, to me at least, to be a literally more infinitely better choice. Of course a truly small and elegant language like V (or maybe Wren) would be more along my line of choice, though for the kind of project like Mercurial, well, as I said, I would have a very hard time arguing against Go.
Well, it also depends on which level of the stack you see a version control tool at. If it is very low, it seems more natural to use a very system-oriented language. You can also see from Fossil that people who are as fit in C as the development team at SQLite can get their hands on developing a high-quality version management tool. Regardless of the fact that Fossil will certainly have problems with the size of the NetBSD repository, I consider Fossil to be one of the most impressive pieces of software I have seen in recent years. Not least because SQLite, Fossil and also the related Tcl are known for their code quality.
A lot of it is certainly also a philosophical question and how to see NetBSD. I see NetBSD as the cleanest Unix available right now. I see it as a self-containing system at every level, which can generate great benefits without external dependencies. By this I also mean that the basic workflow of the software lifecycle for the base system (editing → versioning → compiling → testing) can, for example, be implemented completely with tools from the base system. This ability is limited by the dependency on a tool from pkgsrc, which also brings a lot of new dependencies with it. Then it is no longer so important whether it depends on Go, Rust or something else. As I said - philosophical topic ;-)
Btw, the PerformancePlan [1] and the OxidationPlan [2] are worth reading about Mercurial. The way you want to integrate Mercurial with Rust (change from a Python main to a Rust binary main with an embedded Python interpreter) definitely sounds interesting and according to a good plan. Maybe one day there will be a purely native Mercurial that Python only needs for compatibility with old plugins.
I personally like Golang more than Rust. I chose it to replace a large suite of former Python programs in one of my integration projects and I felt at home right from the start. At Rust, the entry threshold seemed higher for the tasks to be done. On the other hand, Rust is getting a lot of attention in the industry (Microsoft, Facebook) and I would much rather have a Mercurial that is written in C and is part of the base system. But you have to meet somewhere in the middle, and last but not least, someone has to do all the work and as long as I don't have the resources myself, I will avoid asking for anything.
Kind regards Matthias [1] https://www.mercurial-scm.org/wiki/PerformancePlan [2] https://www.mercurial-scm.org/wiki/OxidationPlan