Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GoBGP: BGP Implemented in Go

github.com

Post reply on HN
Print view View original

71–80 of 130 posts

Re: GoBGP: BGP Implemented in Go

#71

Post by im_down_w_otp »

15155 wrote: post #34
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.

You want ponylang.org

Concurrency & parallelism primitives + safety.

Re: GoBGP: BGP Implemented in Go

#72

Post by steveklabnik »

wolf550e wrote: post #64
steveklabnik wrote: post #55

Earlier quoted context omitted.

The Rust approach is, Rust's safety guarantees work for concurrency, but the details of that concurrency are left up to libraries, not the language. Since the safety is in the language, things are always safe, but you get the flexibility to do what you need. You have to remember, Rust is a systems language. Which means that you need access to what the system gives you, and that means at least OS threads and both sync…

That's excellent and must be this way to allow programming microcontrollers or linux kernel modules in Rust, but you guys also need a blessed cross platform N:M threading async I/O sockets and files library, so people can write snmp/mail/web/etc servers/proxies/etc in Rust.

So, mio is certainly becoming the core library everyone uses for async I/O, but N:M threading is more complex, and doesn't have any libraries that are mature enough yet to start consolidating. I think AIO is more important than the threading model for this kind of thing, personally, but it's also not exactly my area of expertise.

Re: GoBGP: BGP Implemented in Go

#73

Post by bogomipz »

baq wrote: post #58
pjmlp wrote: post #52

Earlier quoted context omitted.

Static linking is also a thing in C. Apparently gcc seems to be the only C compiler lacking this capability, thanks to glibc. Also, you can use dynamic linking in Go since version 1.5.

i don't know if it counts, but there's musl-gcc, right?

curious, is there no glibc solution? Its just the libnss* that requires dynamic linking?

Re: GoBGP: BGP Implemented in Go

#74

Post by tptacek »

zzzcpan wrote: post #65
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…

Go is missing a few things for this. There is no good predictable event-driven polling library for networking with proper error handling and no GC pressure (no heap allocations), etc. And it has to implement its own syscall wrappers, because Go's syscall wrappers on non-blocking FDs call into the scheduler and even produce garbage on some errors. TLS library needs to be predictable too, produce no garbage and play we…

There's no good predictable event-driven polling library for networking because the whole runtime is a good predictable event-driven polling library for networking. You're not supposed to "event" Go I/O.

Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access").

With the exception of NTP, I can't see a single example of a service in the list I provided that is sensitive to "GC pauses" on the scale you'd end up with in an idiomatic Go program.

Re: GoBGP: BGP Implemented in Go

#75

Post by dcposch »

alanctgardner3 wrote: post #51
noja wrote: post #31

Earlier quoted context omitted.

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).

The repo maintainers are going to be on the hook to rebuild every dependency every time any package in the dependency chain changes. That sounds like a nightmare versus the current scenario where only one package gets revved when a library has a bug.

Not every time a library changes, only every time one has a security bug.

Re: GoBGP: BGP Implemented in Go

#76

Post by pjmlp »

vbernat wrote: post #68
pjmlp wrote: post #52

Earlier quoted context omitted.

Static linking is also a thing in C. Apparently gcc seems to be the only C compiler lacking this capability, thanks to glibc. Also, you can use dynamic linking in Go since version 1.5.

gcc has no problem with static linking. glibc can be statically linked (with gcc or clang) except the pluggable parts, which is NSS. How would you reconcile static linking and plugins?

By making use of plugin selection at compile time, like we used to do when dynamic linking wasn't available in mainstream OSes.

Re: GoBGP: BGP Implemented in Go

#77

Post by IshKebab »

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…

> 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 includes monitoring security-announce lists for eight different products, where before I monitored the security-announce list for my distro.

But say your distro includes the Go versions, but not the C ones... You're basically complaining that your distro doesn't include everything.

Re: GoBGP: BGP Implemented in Go

#78

Post by tptacek »

dsr_ wrote: post #40
tptacek wrote: post #29

Earlier quoted context omitted.

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…

If the Debian people don't want to include Go for some logistical or religious or religiously logistical reason, that's fine with me. I don'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's notice, rather than waiting for the upstream synchronization dance --- but hardly anyone seems to agree with me on that, either.

But I notice you didn'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 three separate fucking times. Can I at least be rewarded for that by winning a dumb message board argument!?

There's even a cool trick to implementing BER encoders I could have talked about!

Instead, it looks like the thread is going to be about dynamic versus static linkinnzzzzzzzzzzzzzzzzzz.

Re: GoBGP: BGP Implemented in Go

#79

Post by dlanouette »

hartator wrote: post #53
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…

I was thinking Go is implemented in C?

That used to be the case. But with v1.4, it's mostly (all?) in golang now.

http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrit...

Re: GoBGP: BGP Implemented in Go

#80

Post by noja »

alanctgardner3 wrote: post #51
noja wrote: post #31

Earlier quoted context omitted.

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).

The repo maintainers are going to be on the hook to rebuild every dependency every time any package in the dependency chain changes. That sounds like a nightmare versus the current scenario where only one package gets revved when a library has a bug.

So either the repo maintainers do it, or they stop being relevant (for this use case). Or someone else comes along to fill the gap.
Post reply on HN