* Authority DNS
* DNS caches
* ntp
* SMTP
* SSH
* IMAP (added later)
* SNMP
* PBX/Telephony
Fortunately, as time goes on, fewer and fewer people need to run these services at all.
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.
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.
Next:
I'm pretty sure you can'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.
Can these problems be solved? Sure. Are they ready right now? Not that I'm aware of. Please enlighten me, if you have good answers.
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 infrastructure is a superset of C's, and, if you're a masochist, almost everything in C's deployment toolkit is available to Go projects as well.
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.
But say your distro includes the Go versions, but not the C ones... You're basically complaining that your distro doesn't include everything.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
(Sorry for being light on details; typing from phone)
You could handle it the same way that python handles it. Don't rely on a distro, have each person package their own stuff.
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.
https://security.stackexchange.com/questions/56069/what-secu...
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.
Go does not have truly async I/O. It has a userspace (M:N) implementation of threaded, synchronous I/O. There is a distinction, and it's not an academic one.
Rust uses the kernel-level (1:1) implementation of threaded, synchronous I/O, with async I/O provided by mio if you want it.
There is no meaningful distinction between Go's language-level primitive channels and Rust's MPSC channels in the standard library. Not supporting generics is a good reason to put channels directly in the language, but that doesn't apply to Rust.
Additionally, I don't see how Go provides any parallelism primitives that Rust doesn't. In fact, Rust's parallelism (particularly data parallelism) libraries far exceed the capabilities of Go's, mostly because of SIMD and generics which allow you to build highly optimized data parallel abstractions. If I tried to parallelize the project I work on in Rust using Go's built-in primitives, it would be far slower than sequential.
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.
Concurrency & parallelism primitives + safety.
(In particular, note that SSH daemons can fail in many ways other than by remote code execution.)
In the long run, C's role is indeed shrinking - but let's not be too hasty.
But most of what people do with SSH in a devops context isn't interactive; it's a simple control channel for well-defined sequences of file transfers and commands.
I'd prefer a minimal, Go/Rust-based SSH server for my EC2 servers, for instance.
I don't know why I'd prefer OpenNTP to a Go/Rust NTP. What's the advantage to it? OpenNTP is carefully built to avoid a class of bugs that its implementation language is very susceptible to. Go/Rust simply don't have those bugs at all. The latter seems like the safer option.
Same goes for DNS.
Doing it in idiomatic way and dealing with all that goroutine per request model, concurrent memory access and unpredictable GC pauses is simply not worth it. It's going to be safer, but not of a decent quality. Better to live with what we have.
For Rust, I imagine, it's going to take even more work.
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.
Granted, that uses pfring pretty substantially, but still...
[0]: https://twitter.com/brianhatfield/status/692778741567721473
ntppool.org uses golang for DNS https://news.ntppool.org/2012/10/new-dns-server/
just curious about this: are there folks trying out dpdk with go ? implementing these control-plane applications in vanilla sockets (or close-to-zero-wrappers on those), doesn't seem fruitful anymore.
fwiw, i have been doing dpdk stuff, but have been mostly using C...
the sheer number of person-hours at developer salary rates in north america would probably amount to at least a few million dollars.
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...
http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrit...
Operational experience at scale is needed to know how to write an effective SMTP implementation, and that experience is half-documented by many people in many different information silos.
But... I'd also say it's an extremely forgiving protocol. In fact, it's the fact that it's so forgiving which makes operational experience required to implement it. A "correct" SMTP implementation has a lot of latitude in the choices it makes - and it's that latitude which makes life difficult.
Off-hand, you could use GoBGP to do cheap loadbalancing-ish things without external dependencies.
Seeing the same trend with Go now. Why add the language name to the software name? Real question...
I don't really like the language-name-prefix thing either. It makes the language seem like the important thing about the project. Sometimes it is the most important thing, but even then, that is mostly only true at the beginning of a project when attracting contributors is most critical. But I'm not sure the other approaches are much better.
The problem with those sorts of projects however, is inertia. The average hobbyist rarely ever uses BGP. Large networks and ISPs aren't going to implement my personal project as a critical component to keeping their entire infrastructure online without a very good reason.
This project looks promising, I'm hoping it doesn't suffer this problem.
Suggestion: include a quick abstract what what BGP is with a link for more information.
Even if you're not a huge ISP, it's handy to have a BGP implementation available because you can use it to do network analytics and traffic management.
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.
But it can be helpful for topics with ambiguous acronyms or tech. names (Apple) Swift vs. (OpenStack) Swift, for example.
