> I don't know if rewriting MH in go or rust would be better. I am
> half-way through each book (one in each bathroom...).
No, not Rust. Eric has summed up its problems quite a few times and
mentioned it in those three `Go's replacing C' posts I gave. It lacks
Go's pedigree, self-restraint, mind share, clarity, workforce...
The Rust Reference. https://doc.rust-lang.org/reference
While Rust does not have a specification, the reference tries to
describe its working in detail. It tends to be out of date.
In contrast https://golang.org/ref/spec is what the implementations
refer to when deciding who's wrong. Occasionally, it's fixed, but it's
short, written with pride; like Appendix A of K&R. (An example of a
recent fix was a real-number constant might be too small for an IEEE
double, causing the double to be assigned zero. But if it was a
negative constant, should that be an IEEE -0 or +0? Two compilers
differed, the spec. settled on +0 because -0 is an IEEE aberration.)
Not that I've ever used Rust, but that means my bias is untainted by
bitter experience. Disclosure: I have earnt a crust writing Go.
> Either way, I think it needs to be incremental... to maybe wrapping
> the (C) library and writing new daemons on top of it would make the
> most sense.
We don't have a C library. Not really. We have a bunch of C files
split across two and a bit directories giving two `.a' archive files,
and some of the C files link against those, e.g. scan.c and scansbr.c.
But the source doesn't particularly split into decoupled, well-defined
parts. Thus Ken's aim to re-shape the source so libraries are possible,
e.g. for third-party use. Getting there just to then call it from Go
would be a bit of a waste.
If another language were to sidle in then I think smaller programs would
be first, e.g. mhparam and mhpath, ones that didn't have to delve into
inbox/42 but still had to know about all the periphery. Then one way to
elbow a C version out the way would be for C rmm, say, to remain what
the user runs, but execve() the Go version when it knows the work is a
subset that the Go currently implements, e.g. no -rmmproc.