Eric S. Raymond via devel writes: > My choice for a language to move to would be Go. Possibly one of you > can argue for a different choice, though if you agree that Go is a > suitable target I would find that information interesting.
Since the last round of discussion both sides of the argument have been moving. If you believe that Rust will become a first-class implementation language for the Linux kernel, that would tip the scales in favor of rust considerably in my view. Most importantly that seems to ensure long-term support for one of the main target platforms for ntpsec. Both language eco-systems have drank a bit too much from the DevOps cool-aid (no, I don't trust any of your code registries or I could have installed an ntpd in Rust or Go already) and ntpsec would be well advised to figure out how to deal with the inevitable dependencies before it starts. I'd argue that Go would be a mistake for the daemon component and most of the library even without that consideration (Rust has deterministic runtime behaviour, Go does not -- by design). The user facing code I could easily see moving to Go, but these are already rewritten in Python, so why bother with yet another language? I still think that these discussions are somewhat premature since the ntpd of today is this monolithic thing that forges together a bunch of rather disparate things. But changing both the software architecture and the implementation language at the same time is always iffy, so one would have to think really hard about what to do first. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel