Is it time to plan a move to Go?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> >>> libntp
> >> Why do we need a python extension?  Can't we convert ntpclients to Go?
> > Yeah, that'd be be kind of a mess.   ...
> 
> Then we leave that chunk of libntp available for Python.  It won't be very 
> big.
> 
> 
> >> Maybe that would be a good time to split the refclocks out to separate 
> >> programs.
> > Wouldn't make the problem go away.  Whether they're inline of ntpd or
> > separated, either they have to be translated to Go or C persists in the
> > language mix. 
> 
> It means we don't have to port that code to Go.  I'd be happy to drop 
> refclocks on the first cut and develop the new/wonderful refclock interface 
> in Go rather than c.
> 
> The refclock code would be running in a separate address space so bugs in a 
> refclock don't pollute the main ntpd.

I think all your suggestions are reasonable.  On the other hand, they touch
choices we'd probably be best off deferring for a few months anyway. The
Go ecosphere is moving pretty fast, and the expected value of our options is
correspondingly likely to shift.

For example, if Gopy gets itself together to support Go versions past
1.6, moving libntp out of C will start to look pretty attractive.

The important thing to evaliate at this point is whether starting Goi
development looks likely to end us up in a cul-de-sac with *no* reasonable
path forward.  That worst case is looking less likely as we develop
alternatives.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.