<story><title>GoBGP: BGP Implemented in Go</title><url>https://github.com/osrg/gobgp</url></story><parent_chain><item><author>dsr_</author><text>The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go&amp;#x2F;Rust equivalents, unless they handle packets directly.&lt;p&gt;My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of view of a group which does one thing, but not from my point of view, running large numbers of diverse systems.&lt;p&gt;When libfoo gets updated, all N packages on the system which use it via dynamic linking gets the benefit as soon as the packages restart. This is highly desirable.&lt;p&gt;If Go-libfoo is updated, each of those N packages needs to be rebuilt, but I don&amp;#x27;t have a programmatic way of finding out.&lt;p&gt;If there are N teams developing those packages, some of them will be faster off the mark than others, and now I have a window of vulnerability that is larger than the one I had when I could update libfoo on day 1.&lt;p&gt;You have multiplied my workload. I won&amp;#x27;t do that without a really good reason.</text></item><item><author>tptacek</author><text>No. I&amp;#x27;ve written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that&amp;#x27;s just not the case for SNMP&amp;#x27;s BER.&lt;p&gt;The whole &lt;i&gt;point&lt;/i&gt; of using Rust or Go instead of C is that the &amp;quot;peril&amp;quot; of implementing things like ASN.1&amp;#x2F;BER is pretty much eliminated.&lt;p&gt;As for your former point: I don&amp;#x27;t follow. Go&amp;#x27;s deployment infrastructure is a superset of C&amp;#x27;s, and, if you&amp;#x27;re a masochist, almost everything in C&amp;#x27;s deployment toolkit is available to Go projects as well.</text></item><item><author>dsr_</author><text>...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates.&lt;p&gt;Let&amp;#x27;s say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library.&lt;p&gt;My distro ships all the packages noted above, but not their Go-equivalents, so my work load now includes monitoring security-announce lists for eight different products, where before I monitored the security-announce list for my distro.&lt;p&gt;I need to be able to rebuild all eight systems myself, rather than getting automatic package updates to my test systems, and then promoting the packages through alpha and then production. Go is nicer than some other languages about that, but it builds binaries, not packages.&lt;p&gt;Next:&lt;p&gt;I&amp;#x27;m pretty sure you can&amp;#x27;t build an snmpd without ASN.1 parsing, and ASN.1 parsing is the very model of a fraught and perilous splatter-fest. Will the Go ASN.1 parser be better maintained than libtasn? Maybe, maybe not. Repeat this for everything else.&lt;p&gt;Can these problems be solved? Sure. Are they ready right now? Not that I&amp;#x27;m aware of. Please enlighten me, if you have good answers.</text></item><item><author>tptacek</author><text>This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I&amp;#x27;m not sure why you wouldn&amp;#x27;t seriously consider replacing any of the following with Go (or Rust) programs:&lt;p&gt;* Authority DNS&lt;p&gt;* DNS caches&lt;p&gt;* ntp&lt;p&gt;* SMTP&lt;p&gt;* SSH&lt;p&gt;* IMAP &lt;i&gt;(added later)&lt;/i&gt;&lt;p&gt;* SNMP&lt;p&gt;* PBX&amp;#x2F;Telephony&lt;p&gt;Fortunately, as time goes on, fewer and fewer people need to run these services at all.</text></item></parent_chain><comment><author>tptacek</author><text>If the Debian people don&amp;#x27;t want to include Go for some logistical or religious or religiously logistical reason, that&amp;#x27;s fine with me. I don&amp;#x27;t think people should run critical infrastructure from Debian releases --- when things go wrong, you want to be prepared to patch source on a moment&amp;#x27;s notice, rather than waiting for the upstream synchronization dance --- but hardly anyone seems to agree with me on that, either.&lt;p&gt;But I notice you didn&amp;#x27;t respond to my SNMP point, which is disappointing, because I was hoping that at least some fake Internet points might accrue to my otherwise fruitless efforts at implementing SNMP from scratch &lt;i&gt;three separate fucking times&lt;/i&gt;. Can I at least be rewarded for that by winning a dumb message board argument!?&lt;p&gt;There&amp;#x27;s even a cool trick to implementing BER encoders I could have talked about!&lt;p&gt;Instead, it looks like the thread is going to be about dynamic versus static linkinnzzzzzzzzzzzzzzzzzz.</text></comment>
<story><title>GoBGP: BGP Implemented in Go</title><url>https://github.com/osrg/gobgp</url></story><parent_chain><item><author>dsr_</author><text>The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go&amp;#x2F;Rust equivalents, unless they handle packets directly.&lt;p&gt;My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of view of a group which does one thing, but not from my point of view, running large numbers of diverse systems.&lt;p&gt;When libfoo gets updated, all N packages on the system which use it via dynamic linking gets the benefit as soon as the packages restart. This is highly desirable.&lt;p&gt;If Go-libfoo is updated, each of those N packages needs to be rebuilt, but I don&amp;#x27;t have a programmatic way of finding out.&lt;p&gt;If there are N teams developing those packages, some of them will be faster off the mark than others, and now I have a window of vulnerability that is larger than the one I had when I could update libfoo on day 1.&lt;p&gt;You have multiplied my workload. I won&amp;#x27;t do that without a really good reason.</text></item><item><author>tptacek</author><text>No. I&amp;#x27;ve written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that&amp;#x27;s just not the case for SNMP&amp;#x27;s BER.&lt;p&gt;The whole &lt;i&gt;point&lt;/i&gt; of using Rust or Go instead of C is that the &amp;quot;peril&amp;quot; of implementing things like ASN.1&amp;#x2F;BER is pretty much eliminated.&lt;p&gt;As for your former point: I don&amp;#x27;t follow. Go&amp;#x27;s deployment infrastructure is a superset of C&amp;#x27;s, and, if you&amp;#x27;re a masochist, almost everything in C&amp;#x27;s deployment toolkit is available to Go projects as well.</text></item><item><author>dsr_</author><text>...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates.&lt;p&gt;Let&amp;#x27;s say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library.&lt;p&gt;My distro ships all the packages noted above, but not their Go-equivalents, so my work load now includes monitoring security-announce lists for eight different products, where before I monitored the security-announce list for my distro.&lt;p&gt;I need to be able to rebuild all eight systems myself, rather than getting automatic package updates to my test systems, and then promoting the packages through alpha and then production. Go is nicer than some other languages about that, but it builds binaries, not packages.&lt;p&gt;Next:&lt;p&gt;I&amp;#x27;m pretty sure you can&amp;#x27;t build an snmpd without ASN.1 parsing, and ASN.1 parsing is the very model of a fraught and perilous splatter-fest. Will the Go ASN.1 parser be better maintained than libtasn? Maybe, maybe not. Repeat this for everything else.&lt;p&gt;Can these problems be solved? Sure. Are they ready right now? Not that I&amp;#x27;m aware of. Please enlighten me, if you have good answers.</text></item><item><author>tptacek</author><text>This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I&amp;#x27;m not sure why you wouldn&amp;#x27;t seriously consider replacing any of the following with Go (or Rust) programs:&lt;p&gt;* Authority DNS&lt;p&gt;* DNS caches&lt;p&gt;* ntp&lt;p&gt;* SMTP&lt;p&gt;* SSH&lt;p&gt;* IMAP &lt;i&gt;(added later)&lt;/i&gt;&lt;p&gt;* SNMP&lt;p&gt;* PBX&amp;#x2F;Telephony&lt;p&gt;Fortunately, as time goes on, fewer and fewer people need to run these services at all.</text></item></parent_chain><comment><author>nickpsecurity</author><text>He gave you a really good reason: knocking out most severe, low-level errors in high-usage, critical services. You&amp;#x27;ll put work in for the risky ones. Why not the low-risk alternatives...</text></comment>