Live data from Hacker News

GoBGP: BGP Implemented in Go

github.com

41–50 of 130 posts

Re: GoBGP: BGP Implemented in Go

#41
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…

Cloudflare mentions they are heavy users of a golang DNS lib https://blog.cloudflare.com/dns-parser-meet-go-fuzzer/ ntppool.org uses golang for DNS https://news.ntppool.org/2012/10/new-dns-server/

Cloudflare is a heavy user of Go period.

Re: GoBGP: BGP Implemented in Go

#42
post #6

Earlier quoted context omitted.

I'm not aware what BGP is, clicked hoping to find out, was sorely disappointed.

bgp A project page for a $language implementation of $protocol shouldn't be expected to give a basic description of $protocol. If you care about a new implementation, you already know what the protocol does, at least generally. If you're lucky, the project page links to a protocol description (possibly at wikipedia), or, as above, you can simply google it yourself and then decide whether a $language implementation of…

I don't think it's a lot to ask for a readme to contain the full name of the acronym it's implementing and maybe a link to a wikipedia page.

I mean, it already has a link to the golang website, but no mention of what BGP actually is.

Re: GoBGP: BGP Implemented in Go

#43
post #34
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.

In general, almost every stdlib will be "better" than Rust's, as we're taking an "anti-batteries included" approach.

And while Go does have great built-in stuff for a certain kind of concurrency, Rust's approach is more flexible and safer. It's a tradeoff, not a "far exceed" in my mind.

Re: GoBGP: BGP Implemented in Go

#44
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.

You'd be surprised. Go actually has a supported SSH library which is a fairly decent protocol-level implementation. To actually get a "shell server" you would need to implement handling of SSH sessions (as described in the RFCs) but all the low level stuff is taken care of.

EDIT: As an example, the gogs project has implemented a small ssh server so people running it don't need to hook into OpenSSH, which relies on specific versions of OpenSSH to be performant. See https://github.com/gogits/gogs/blob/master/modules/ssh/ssh.g...

Re: GoBGP: BGP Implemented in Go

#45
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…

Animats suggested the same kind of services for Rust projects as well given huge benefits of less memory attacks in critical services. Im in total agreement while throwing in they should preferrably be compact so vendors put them in commercial routers and appliances.

Re: GoBGP: BGP Implemented in Go

#46

Earlier quoted context omitted.

Is that necessary? I'm not sure how many people are unaware of what BGP is.

This is just classic karma mongering by running Google for other people and posting the result. So no prob. not necessary. But it can be helpful for topics with ambiguous acronyms or tech. names (Apple) Swift vs. (OpenStack) Swift, for example.

Addressing multiple comments here, but to your point specifically: I don't really care about karma. I would've preferred exactly what I recommended to the author, instead of spending the time to google it and posting a comment.

In general: We can all be better teachers. Acknowledging that not everyone who writes code in Go shares the same background, training or interests is a good step to getting more people to use Go.

Re: GoBGP: BGP Implemented in Go

#47
post #40
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…

He gave you a really good reason: knocking out most severe, low-level errors in high-usage, critical services. You'll put work in for the risky ones. Why not the low-risk alternatives...

Re: GoBGP: BGP Implemented in Go

#48
post #30
post #28

Earlier quoted context omitted.

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code. Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

I didn't say it was. But then: I don't trust that Cisco C code at all . Do you?

In the decade I worked at an (smaller, regional) ISP, there were a number of times that I know of that Cisco provided a custom firmware to us get around a bug we found that prevented regular configuraitons from working as expected. Considering the scale of Cisco, and that we were small enough at the time to need less than five people in network operations, I find that terrifying. They weren't security issues, but it does point towards their code base being too complex for them to adequately manage.

Re: GoBGP: BGP Implemented in Go

#49
post #34

Earlier quoted context omitted.

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.

In general, almost every stdlib will be "better" than Rust's, as we're taking an "anti-batteries included" approach. And while Go does have great built-in stuff for a certain kind of concurrency, Rust's approach is more flexible and safer. It's a tradeoff, not a "far exceed" in my mind.

Isn't the Rust approach the Ruby, Python, or C++ approach?: give pthreads, rely on the community to produce a fragmented, incompatible ecosystem.

Re: GoBGP: BGP Implemented in Go

#50
post #15

I look forward to the first programmer friendly SMTP/IMAP implementation. Haraka is the closest friendly SMTP server I have come across.

I can understand why there hasn't been much movement in the SMTP world. SMTP is pretty hard to get right, as is maybe hinted at by the many RFCs. You really don't want to be making any mistakes because it's a somewhat unforgiving protocol... unless you send an error code.
Post reply on HN