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
