Go has a GC. the Go standard library and the complier implementation will
always be utterly controlled by Google, and will be full of Google magic.
Go's usecase is to solve Google's problems, and can basically be modelled
as "compiled Python that forcefully avoids all of the kinds of typos that
Dr
On Mon, Sep 12, 2016 at 8:14 PM, Eric S. Raymond wrote:
> While this is in some ways a tempting thought, I think the energy we
> might spend on this would be better directed towards a newer language
> that *is* suitable for soft realtime and has good provability properties
> for security. Rust o
we are not making Rust part of NTPsec right now. but maybe in a year or
so, at this pace
On Mon, Sep 12, 2016, 12:54 PM Hal Murray wrote:
>
> e...@thyrsus.com said:
> > Every Unix-like system, for sure. Checking...Rust has a Windows port. So
> > does Go. Are there any other tarhets you're wor
e...@thyrsus.com said:
> Every Unix-like system, for sure. Checking...Rust has a Windows port. So
> does Go. Are there any other tarhets you're worried about?
Mostly just curious. I've never used either.
I see go on FreeBSD and NetBSD. I see rust on FreeBSD but not on NetBSD.
--
These are
Hal Murray :
>
> e...@thyrsus.com said:
> > While this is in some ways a tempting thought, I think the energy we might
> > spend on this would be better directed towards a newer language that *is*
> > suitable for soft realtime and has good provability properties for security.
> > Rust or Go seem
e...@thyrsus.com said:
> While this is in some ways a tempting thought, I think the energy we might
> spend on this would be better directed towards a newer language that *is*
> suitable for soft realtime and has good provability properties for security.
> Rust or Go seem like the obvious candida
Hal Murray :
> It's worth considering writing something like a ntp-lite in Python. It would
> probably take a handful of shims to get at OS calls that Python doesn't
> support directly.
>
> Consider a client-only, no refclocks implementation. The timing parts are't
> that tricky. The OS pro
e...@thyrsus.com said:
> Going forward, one of the improvements I intend to pursue is moving
> everything in the suite other than ntpd itself into Python. I'd move ntpd,
> too, if it were practical, but Python's virtues do not include being any
> good for realtime work.
It's worth considering w
With Zero Perl Day just achieved, this seems like a good time to
review what I see as NTPsec's longer-term objectives. This note
has two purposes. First, to explain why I've been prioritizing
our technical efforts as I have. Second, to invite comment and
direction from CII if t
