NTP - big picture

[Eric S. Raymond]

Richard Laager <rlaager at wiktel.com>:
> On 1/31/19 10:24 PM, Eric S. Raymond wrote:
> > Replacing Python with Go should happen first for these reasons:
> > 
> > (a) It's much easier than replacing the C.  Thus, it will give those of us
> > with weak or noexistent Go skills time and room to ramp up. (Ian and I are
> > already fluent.)
> > 
> > (b) Python library management is a mess that we want to get shut of.
> 
> I see why it would be beneficial to use the utilities as an opportunity
> for people to learn Go. Is someone other than you or Ian going to do
> that porting work? If not, it won't be useful for that purpose, though.

Well, I did hope the work would get spread around a bit more.

> Even if it is useful for learning, it's not without trade-offs. The core
> assumption here is that more people know Python than Go. That's why
> people need an opportunity to learn Go.

Indeed. But there's a bit of a special circumstance here. The costs aren't
antything like what is historically normal for a language move.

The semantic distance between Python and Go is *low*. Translating from
one to the other is so easy that I was able to write a Python script
that does about 85% percent of the job *without having a Python parser
in it*.  It's all local transformations with regexps.

(I tested it on 14KLOC of reposurgeon's Python code, successfully
translating 90% of it as verified by regression tests before I had to
go full speed on NTS.)

This implies that the barrier for *humans* between Python and Go is
also very low. Once Python programmers (in general) get the idea that
knowing Go is worthwhile, I expect them to become fluent extremely
rapidly.  This makes "more people know Python" much less significant
than it would be for "more people know X" with X at greater
semantic distance.

> Python is an incredibly popular language that is very easy to edit for
> debugging--including in situ on an installed system. For example, you
> can just throw in print statements. You'd be replacing that with
> something far less well known, which produces binaries (which are much
> harder to debug).

Inserting fmt.Printf() calls works just as well in Golang as inserting
prints does in Python.  The only speed bump is in making the binary. The
Go devs have miminized this with "go run".  That is,

	python hello_world.py

becomes

	go run hello_world.go

Also, Go throws useful traces on a runtime error as Python does.

> Also, if a sysadmin wants to build something custom, copying one of the
> existing Python utilities and incrementally editing it is vastly easier.

Don't assume that until you've customized some Go code yourself.  The
Gophers learned a *lot* of lessons from Python.  So much so that it's
not stretching much to view Go as Python's direct successor.  Google
sees it that way - follow the funding stream.

(The wacky part is that you can also view it as C's direct successor
avoiding the gigantic botch that was C++. The fact that they managed to
unify the strengths of Python and C in one language makes me almost
cross-eyed with admiration.)

> Go seems like much more of a "programmer's language" than a "sysadmin's
> language".

That is to some extent true. But the semantic distance is still very low.

> I don't see the same problems with Python libraries that you do. I have
> used tons of Python libraries in multiple different projects/situations
> and things work fine for me.

I, on the other hand, have been burned twice.  We had systematic
problems with Python libraries on GPSD, too, especially near our one C
extension. The workarounds required in our build system are ugly and
fragile, and GPSD's Debian/Ubuntu packager is permanently pissed off
about them.

I dealt with it at the time because Python was then the handiest tool
available.  That was before the 2-to-3 transition became a real issue,
before I ran into the limitations of the GIL, and before reposurgeon
taught me a hard lesson about Python's performance limitations on large
datasets.

Now, Python appears to me as an aging, somewhat grubby language whose
future is limited by some unfortunate choices baked into it.  Rather
as Perl was a decade ago.  I don't regret the twenty years over which
it was unequivocally my favorite development language, but times are
changing.

I see a possible future in which Go has replaced both Python and C in the
NTPsec suite, and it's a good future.  I certainly don't see any other
plausible path to reducing our implementation-language count to 1.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190201/243e9622/attachment-0001.bin>