Objectives for the next year

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> > I'll start the ball rolling with this big one:  It's time to move out of C.
> 
> I want to threadify things, and taking advantage of that, I want to run at 
> full wire speed on a gigabit link with a modest server class CPU.
> 
> I have test code running.  I'm pretty sure it will work.  But my test code is 
> in C.
> 
> Are other people happy with threads?

I am now.  Working with Go for the last couple of years has nrought me up to
speed on that kind of programming.

> I think threadifying things will allow us to clean up the code a lot.  I think 
> that may be as important for writing safe/clean code as moving out of C.

I think you are right.  However, I'm pretty sure we should change
languages before we threadify.  Both Rust and (especially) Go have concurrency
primitives that are *far* more tractable than their rough C equivalents.

> > My choice for a language to move to would be Go.
> 
> The only other choice I've seen seriously mentioned is Rust.  How do they 
> compare for thread support and for CPU cycles?  Do they have full access to 
> all the options for network I/O?  (for example recv time stamps)
> 
> My first reaction is that I don't want reference counted stuff involved with 
> network I/O.  But maybe that is bogus.  It's roughy 5 microseconds for a 
> recv/send pair in C. We should write some test code so we can get some real 
> timing numbers.

There are two major issues with Rust:

1. We have at least two people who are expert Go programmers - Ian and
myself.  We have nobody, AFAIK, who is up to speed on Rust.  Moving
the code will be a large amount of work - I don't think any good
purpose is siolved by adding "learn to be fluent in an entire new
language" on top of that.

2. I don't think Rust is as yet stable enough for our purposes. The
language and core libraries are still in some flux - we can't yet
count on a feature we're relying on not disappearing over the next
decade.  This is a very srtark contrast with Go's ironclad
forward-compatibility guarantee.

For me, issue #2 is the real dealbreaker.

As for your questions: Both languages have reasonable threading
support, far better than C's.  Rust would be more abstemious of
processor cycles than Go is, but I dont believe the difference
is significant for our deployment.

Full access to all aptioons for betwork I/O: I believe pure Go can be
beaten into this, but that corner of the API is very poorly
documented so I don't know exactly how yet.  We have the option of
using cgo and writing small C extensions to gety at things the Go
API doesan't suppport.

I don't knpw of anuy direct support for things like recv time stamps
in Rust.  But Rust also has a facility to call C extensions.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>