61–70 of 130 posts
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?
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…
You could handle it the same way that python handles it. Don't rely on a distro, have each person package their own stuff.
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?
Earlier quoted context omitted.
Isn't the Rust approach the Ruby, Python, or C++ approach?: give pthreads, rely on the community to produce a fragmented, incompatible ecosystem.
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…
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…
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.
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 authorit…
https://security.stackexchange.com/questions/56069/what-secu...
Earlier quoted context omitted.
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…
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 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.
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.
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…
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
(Sorry for being light on details; typing from phone)