Re: Checking out src with Mercurial

[Jan Danielsson <jan.m.danielsson%gmail.com@localhost>]

On 2020-06-19 18:56, Sad Clouds wrote:
[---]
> What I find a bit strange is the idea that developing something in
> Python + C, then re-writing it in a hipster language like Rust, is more
> reliable than just using well designed C/C++ code.

   Even some of the most ardent Rust evangelists say "Don't rewrite in
Rust for the sake of rewriting in Rust".  But specifically with regards
to Mercurial it's a story which is much more related to Python 2 -> 3,
and how painful that transition was.  It's a long, but interesting,
story; well worth a read, imho:
https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/

   The tl;dr for those who don't want to read all that:  If, five years
earlier, Rust had been in the shape it was when that post was written,
the Mercurial developers may have opted to port to Rust rather than try
to bend Python 3 to their will -- because many common assumptions they
made about Python were true in 2.x, but not 3.x.

   Regarding choosing Rust over "well designed C/C++ code":  Going by
the blog, it seems some of their core developers really like Rust.  I
imagine that the OsString/OsStr issue is probably quite relevant to
[portable] source management systems; probably things like that matter
to them.

> OK C is not perfect, but if software reliability is the main concern,
> how many control systems operating aircraft, railway, or nuclear power
> station are written in Python or Rust? Probably none.

   Rust doesn't even have a formal specification, so it's probably a
no-go in assurance heavy industries (like the examples you listed).  And
there's the slight issue of not handling[*] OOM in the standard
library..  That said, there's apparently both a working group for
creating an official specification, and I believe there has been a bug
fixed in their type system that was discovered by another group doing
formal verification [based on the defacto specification].

   [*] Well, it's a matter of defining "handling".  "Crash and burn" is
"handling", I guess.

> And as you mentioned, if you can't use the tool on old VAX or SPARC
> machines, that are still supported by NetBSD, the whole point of the
> tool becomes rather irrelevant.

   I know it's cheating for those who want to build on native hardware,
however ..

   I have cried myself to sleep because of Rust a few times, but I will
say:  As long as your project/crates use plain cargo, without build.rs,
then cross-compiling is so trivial that you'll find yourself wondering
what you did wrong.  It took me less than five minutes from never having
done it before, or even read about how to do it, to have my first
project built for armv7.  I copied the binary over to my Zynq-7000 board
and ran it, and it Just Worked(tm).

   There's obviously a nice list of caveats to that; like:
   - Can only cross-compile to what LLVM supports, and they can be
crotchy about adding support for new architectures unless you're willing
to devote your life to supporting and maintaining that code.  (For
background, search for "m68k llvm").
   - Both your host and target platforms are essentially Tier 1 or Tier
2 Rust platforms.
   - Rust sometimes produces *massive* binaries.

   I think SPARC is supported, but cross-compiling to VAX is probably
not going to be an option any time soon -- or ever.  :/

   I think the Mercurial developers' choice to keep Python support
around, and allow Rust for slightly more performant code, is a good
compromise.  I just wish that: 1) Rust was less problematic on NetBSD,
and 2) LLVM supported more [legacy] backends.

-- 
Kind Regards,
Jan