Hi Michael, > 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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers