Using Go for NTPsec

[Hal Murray]

[timing of GC]

> which shows their meassured STW pauses are bounded to about 95% by 600us and
> typically less than 400us. This is consistent with other reports I've seen,
> and that's why I took 600us as a worst case STW we're likely to see. 

I didn't see any description about what was actually going on.  How many 
threads?  How big are the stacks?  How big is the heap?  What are the right 
parameters?

----------

> There is one other that is more important: Rust does not have a stable API,
> certainly not one that we can count on to be solid on decadal scales. Nor
> does it have the kind of development culture that is conducive to API
> stability over decades.  It's a very young language, still in "move fast and
> break thing" mode. 

You may be right.  I haven't written/maintained enough code to confirm or deny 
that.

The language and libraries/crates are both versioned.  It looks like a good 
story to me.

----------


[Receive timestamp]
> I think it can be done in Go but will take some fancy dancing.  I have this
> under acrtive investigation now. 

I'm sure I can do it in Rust too.  The point is that it does take some fancy 
dancing rather than being something the system has already provided.

----------

> Maybe. But I know from previous experience that trying to make major changes
> to a program's architecture *while you're porting it to new language* is an
> invitation to disaster.

> The only strategy that works is to do a stupid, literal, unidiomatic port
> first, verify it, then clean it up and make it idiomatic. 

That would make sense if the structure of the starting code was reasonably 
close to the final goal.  Does it hold if you are going to make major changes 
to the architecture?

----------

[Split out stuff so we can write the time-critical parts in C or Rust.]

> I want to stay away from mixing languages if at all possible.  The joints
> between them are always *serious* defect attractors and major sources of
> maintainence complexity. 

I envision the APIs being text strings over stdin/stdout.  I think they will 
be simple enough so that the joints won't be a serious problem.  Put it on 
your list of options in case you decide you have to do something about GC.

----------

> Picking up new languages *is* one of my strong points, yet I found Rust
> rebarbative in the extreme. This did nothing to make me optimistic about
> finding developers to work in it. 

I think that is the root of our "discussion".  Your version of good/clean 
focuses on the language/environment.  You are willing to (try to) dance around 
run time quirks.  Mine focuses on the runtime.  I'm willing to struggle with 
the language/environment.  Or at lease struggle some more until I learn 
something critical.



-- 
These are my opinions.  I hate spam.