Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

[Ralph Corderoy]

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