Is it time to plan a move to Go?

[Eric S. Raymond]

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
transition.

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. 

Thoughts?
-- 
		<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