Replacing C (was: Re: The end of the beginning is in sight)

[Eric S. Raymond]

Mark: Heads up! Serious discussion of language migration follows.

Achim Gratz <Stromeko at nexgo.de>:
> Eric S. Raymond writes:
> > 1. Performance and algorithm tuning - we need to take a serious swing
> > at Gary's slow-convergence problem, in particular.
> 
> This objective needs to be defined more properly.

Agreed.

> > 3. Move the codebase to Go or Rust?
> 
> While I understand what kind of problem you're trying to solve, at the
> moment I see neither of those two languages survive for long if their
> current parent projects change course (again).

I'm not worried about that for Go, because Google has sunk a lot of investment
into million-line Go programs (like running YouTube and the Chrome download
server). Because those are unlikely to go away, so is its funding case.  This
is actually one of the stronger arguments for Go.

I *am* a little worried about this with respect to Rust.  I don't see
any core project by a deep-pocketed backer anchoring its funding, no
YouTube equivalent.  The Mozilla Foundation is not doing well and
could plausibly crash in a few years.

>                                                  Considering the space
> you're operating in and the objectives you have, another candidate would
> be Erlang/OTP.  Ada has already been mentioned, although I'm not a big
> fan of its overly verbose syntax.  Last but not least, moving the code
> base to some suitably constrained subset of C++ might also be an option.

You raise a good point about Erlang.  I should probably learn it.  One
difficulty that gives me a little pause is translation distance, though.
If we have to hand-translate the code, Go is barely a jump at all; Rust
is somewhat trickier, and Erlang (from what little I know of it) would
probably be significantly trickier than Rust.

(This ordering changes if Corrode really works, at which point the
case for Rust gets rather stronger.  That wouldn't do anything
to reduce Erlang's distance, though.)

I don't know Ada.  Mark does and says he considers it unsuitable.  I'd
like to understand his objections better than I do, but I generally
trust his judgment about such things so it is at the very bottom of my
list of possibilities.

About C++, not just no but hell no.  The point of the move would be to
improve our safety guarantees.  Keeping a codebase inside a "safe set"
of this language requires a kind of discipline that is notoriously
difficult to maintain - your safety guarantees can go poof in a
moment of inattention.

Even ignoring the catastrophic scenario, one of the things I want from
a replacement language is a type system strong enough to really cut the
distance between first attempts and correct code - to put it concretely,
compiler error messages that are *really* helpful. I know that Go really
shines here, I don't yet know how good Rust is (but will learn), and I
know that C++ sucks badly. And that that can't be fixed; the problem
is entailed by the weakness of its type system.

Practically speaking, I don't have time to become fluent in half a dozen
candidate languages. I can probably budget time for one more beyond Go
and Rust; Erlang actually seems like a strong contender there.

The out-of-left-field possibility I've been mulling privately is
Ocaml.  But not very seriously; one of the criteria has to be
accessibility to future maintainers coming out of a C background
and Ocaml doesn't do at all well there.  That's a problem for Erlang,
too, and again a plus for Go.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>