Is it time to plan a move to Go?
Eric S. Raymond
esr at thyrsus.com
Sat Nov 4 23:59:23 UTC 2017
Here's my big question about the next year of development: should we
be moving the codebase out of C to Go?
I think the project is feasible and the potential gains are large, but
I don't want to start anything without being sure our senior devs are
happy with the idea. This means everybody's concerns need to be heard
well before any code is cut.
Go has several big advantages going for it:
* Dynamic allocation. No more overun issues or malloc-related core
dumps, ever. From a security/reliability perspective, this is a
really big deal.
* Comfortable step up from C. It seems to have been designed to be as
C-like as possible given the basic goal of abolishing memory
management by hand. I felt like I was becoming reasonably fluent
with in it within two days or so of a cold start. I don't imagine
any of our senior devs would have a lot more trouble.
* We can be more confident that not going to go away than we could
with any other candidate let's-replace-C languages other than *maybe*
Rust. Google is committed to it, it's got a dev team with huge
prestige, and the reports from early adopters are good. It has
cracked TIOBE's top 20.
* It's rather specifically designed for writing complex application
servers. I've studied the library API and all our odd IP-fu should
be no problem to implement in it.
* Extremely nice concurrency primitives. I can already see how async
DNS lookup would work in Go; it would be simple and *pretty*.
* Dynamic allocation plus a somewhat stronger cross-platform API
means less code to do the same things. I think it's quite possible
we could drop 15% of LOC with a straight translation.
This is not to say moving the code would be a cakewalk. While I don't
expect any really fundamental isses with the move, there are going to
be lots of nasty frictional ones. One of the reasons I want to start
this conversation now is so we can identify and list them before
committing any effort to writing code, and use that list to scope the
Here are some obvious ones:
* Go has its own build system. Use that? Try to beat waf into
building Go binaries with explicit compiler calls?
* Platform-specific hacks like most of ntp_sandbox.c are going to be
a problem. Probably means we have to master calling out to C code
from Go, but I am certain that interface boundary will be a
complexity and defect attractor.
* libntp is a problem - ideally we want to have the Python extension
that wraps it call compile Go rather than C, but that could be
difficult to arrange.
* Not hard to see how to qualify most of the translation, but refclock
drivers we don't have test hardware for are a source of worry. Can
we do anything other than be meticulous and hope?
* Anywhere the C code uses unions will not be directly translayeable.
If we hadn't cut the volume of C by a factor of four and cleaned it up a
lot I think it would be nuts to even try this. As it is, there is
easily six months of hard work here.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The American Republic will endure, until politicians realize they can
bribe the people with their own money.
-- Alexis de Tocqueville
More information about the devel