Nigel Tao <nigel...@golang.org>: > Spun out of the "C++ 11 to Golang convertor" thread... > > > On Mon, Jan 7, 2019 at 12:27 AM Eric S. Raymond <e...@thyrsus.com> wrote: > > Perry and I have two different target languages in mind. Perry's > > target language is basically a repaired C - type-safe, almost > > upward-compatible. He and I have the same strategic goal - draining > > the swamp of old, leaky C code - we're just betting on slightly > > different ways to do it. We intend to cooperate as much as possible. > > This is drifting quite off-topic, but I would expect transpiling C to > Go would result in something slower than the original, especially if > it involves a lot of low-level, slice-of-bytes processing. Faster is > obviously easier to sell than slower.
I agree. The class of old C program I am interested in is, however, not generally limited by CPU but by network and (less commonly) disk stalls. Again bear in mind that my type examples are NTP and DNS service. A lot of other legacy infrastructure code fits this pattern. > Go is memory-safe, but that entails e.g. runtime bounds checking. Any > individual bounds check might be cheap, measured in nanos, but for > e.g. image decoding, a per pixel bounds check multiplied by a > megapixel image (a 'low-res' photo, by today's standards) means that > nanos become millis. Again agreed. Transpilation to Go is only appropriate for cases where nanos becoming millis doesn't matter. Typically, old infrastructure code was designed for platforms now enough Dennard-scaling cycles in the past that Go on current hardware will run faster than C did originally. > Reasonable people can disagree, but I favor rewriting over > transpilation, for draining that swamp. The problem is that in general nobody *does* rewrite old infrastructure code. It tends to work just well enough to fester in place for a long time, and then you get shocks like the Heartbleed bug. It is my aim to head off that sort of thing in the future. > https://github.com/google/wuffs is a new, memory-safe programming > language and a written-from-scratch library of various file formats. > Runtime performance is a special concern: there are no implicit > (runtime) bounds checks. Unlike Go, bounds checks have to be explicit, > which means that programs can eliminate them from the object code by, > well, eliminating them from the source code. That is an interesting and clever approach. I think all three approaches should be in the toolkit. They fit different use cases. -- <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. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
