Replacing C

[Eric S. Raymond]

Achim Gratz <Stromeko at nexgo.de>:
> Eric S. Raymond writes:
> > But how to define that space is itself not entirely clear.  One of the
> > more intelligent comments in the (generally high-quality) discussion of
> > the "Getting past C" blog post argued that because ntpd is more like a
> > network service daemon than an OS kernel, Go is a better fit than
> > Rust. I think there is merit in that argument, and it suggests that
> > the YouTube service *is* "the exact space".
> 
> The part of "servicing several thousand client systems" might be coerced
> into fitting that description, but YouTube doesn't care for the same
> level of consistent latency and/or small jitter and it certainly deals
> with a lot more bandwidth per client than an NTP server would. It also
> describes just one tiny part of what ntpd is used for (low stratum pool
> server) commonly and leaves out the more common case of it being used to
> set the time of a computer based on multiple servers (in contrast to
> sntpd, which uses only a single one).  There may be a chance to untangle
> those use cases by refactoring, but that is then independent of the
> language discussion.

All of what you say is true, but I don't think it invalidates the commenter's
point. Which is, most generally:

* An OS kernel or real-time embedded system really needs zero-overhead
abstractions a la Rust or C. It's almost definitional that latency
spikes at any point are a cause of havoc.

* A network service daemon, whether YouTube or NTP in server mode or
NTP in client mode, has reqirements that aren't quite as stringent.
If it has critical sections, like clock setting or atomic database
access, it's sufficient that those be protected from runtime-induced
latency spikes *within critical regions only*; at other times performance is
sufficiently I/O bound (or enough time is spent in I/O waits) that the
occasional latency spikes from the runtime barely even register.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>