GoBGP: BGP Implemented in Go • Hacker News Board

Re: GoBGP: BGP Implemented in Go

#31

Post by noja » Mon, Apr 18, 2016, 6:05 PM UTC

dsr_ wrote: post #23

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let'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. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

So you install the go equivalents from your distro. If your distro doesn't have them, you vote for them to add them (or go through whatever process your distro has).

Re: GoBGP: BGP Implemented in Go

#32

Post by fogleman » Mon, Apr 18, 2016, 6:10 PM UTC

dragonshed wrote: post #2

I assume BGP == Border Gateway Protocol https://en.wikipedia.org/wiki/Border_Gateway_Protocol Suggestion: include a quick abstract what what BGP is with a link for more information.

This happens fairly often (projects assuming I know the tech they are built on), and I'm no dummy.

I also clicked through several pages on the repo / site and there was no clue as to what BGP was, except some mention of RPC.

Re: GoBGP: BGP Implemented in Go

#33

Post by kev009 » Mon, Apr 18, 2016, 6:11 PM UTC

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

You will be doing battle with the GC in many of these applications. Yes, even 1.5+. 10ms is an eternity to do no workload.

Re: GoBGP: BGP Implemented in Go

#34

Post by 15155 » Mon, Apr 18, 2016, 6:17 PM UTC

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

RE: the (or Rust) comment-

All of these services would be better suited for a language which has blessed async IO, concurrency, parallelism primitives. Go has these, Rust does not. pthreads are not the answer.

I much prefer Rust, but Go's stdlib and concurrency features far exceed that of Rust at the moment.

Re: GoBGP: BGP Implemented in Go

#35

Post by tptacek » Mon, Apr 18, 2016, 6:22 PM UTC

kev009 wrote: post #33

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

You will be doing battle with the GC in many of these applications. Yes, even 1.5+. 10ms is an eternity to do no workload.

The only service in this list that I can see the GC mattering for is NTP, but then, you can design a tight NTP server that virtually eliminates the GC's work in Go, taking advantage of the rest of Go's high-level features that C lacks.

Re: GoBGP: BGP Implemented in Go

#36

Post by tobz » Mon, Apr 18, 2016, 6:23 PM UTC

dsr_ wrote: post #23

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let'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. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

Having the shared library that can be replaced by itself, instead of deploying N things, is nice. Not sure it's the end of the world, but it's nice.

On the flipside, though, this is probably a case where using something like Rust could be excellent: stronger language support for eliminating entire classes of bugs but also able to be compiled down to something that can be a shared library.

I'm not an ML expert, but reading about the things the Mirage project has done related to TLS, leveraging OCaml to provide compile-time guarantees, sounds very exciting. Rust feels like it could be that bridge. Start rewriting core libraries in it: cleaning up old code, removing dead code, avoiding bugs by virtue of the language/compiled, in one fell swoop.

Re: GoBGP: BGP Implemented in Go

#37

Post by walrus01 » Mon, Apr 18, 2016, 6:25 PM UTC

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

replacing openssh with something you've written yourself seems like reinventing the wheel, just because you can.

the sheer number of person-hours at developer salary rates in north america would probably amount to at least a few million dollars.

Re: GoBGP: BGP Implemented in Go

#38

Post by tptacek » Mon, Apr 18, 2016, 6:27 PM UTC

walrus01 wrote: post #37

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

replacing openssh with something you've written yourself seems like reinventing the wheel, just because you can. the sheer number of person-hours at developer salary rates in north america would probably amount to at least a few million dollars.

Except that OpenSSH is a very large, complicated, and featureful piece of C code that most servers need only a tiny portion of.

Re: GoBGP: BGP Implemented in Go

#39

Post by unethical_ban » Mon, Apr 18, 2016, 6:30 PM UTC

tptacek wrote: post #11

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'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

>Fortunately, as time goes on, fewer and fewer people need to run these services at all.

I'm not sure what you mean here. Are you suggesting it's a positive that the Internet is becoming centralized? Why is it "good" or "bad" that lots of people run SSH, their own email, or their own phone server?

Obviously one part is that it's hard to run them correctly, but I would argue the internet may be a better, more authority-resistant mechanism if some of these services were run from each person's home or VM rather than on Google's platform.

Re: GoBGP: BGP Implemented in Go

#40

Post by dsr_ » Mon, Apr 18, 2016, 6:30 PM UTC

tptacek wrote: post #29

dsr_ wrote: post #23

Earlier quoted context omitted.

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let'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. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

No. I'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's just not the case for SNMP's BER. The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated. As for your former point: I don't follow. Go's deployment infrastru…

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly.

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.

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.

If Go-libfoo is updated, each of those N packages needs to be rebuilt, but I don't have a programmatic way of finding out.

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.

You have multiplied my workload. I won't do that without a really good reason.