Hacker News Reader

Comment by cromulen | Hacker News Reader

As opposed to the fuchsia netstack written in Go by Google https://github.com/fuchsia-mirror/netstack

Why so many netstacks in Go? I would imagine even the tiny GC pauses Go has would be undesirable for a netstack.

Fuchsia's netstack is based off this netstack. Fuchsia's netstack is essentially a wrapper of this netstack with link endpoint implementations to access NICs via magenta.

GC systems programming languages are a thing since Xerox PARC, the only part missing so far, was having a well known company with the political willingness to push them into mainstream at whatever cost, regardless of what the anti-GC crowd thinks.

tcp was designed a long time ago when computers were slow, and precise timing is not a hard requirement; also you can design a stack so it doesn't allocate in the fast path (gc or not, allocation is slow). That said, Go is still a weird choice as the runtime is not ideal for system applications.

Not really, here are some examples of systems done with GC enabled systems programming languages.

https://github.com/ycoroneos/G.E.R.T

https://archive.org/details/bitsavers_xeroxparcteCedarProgra...

http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf

http://www.projectoberon.com/

http://www.ocp.inf.ethz.ch/wiki/Documentation/Kernel

https://en.wikipedia.org/wiki/ARX_(operating_system)

https://en.wikipedia.org/wiki/SPIN_(operating_system)

https://www.amazon.com/Programming-Modula-3-Prentice-Innovat...

I specifically said gc was not an issue but that Go's weird threaded runtime was more of an problem. You missed Mirage from your list, among others.

I specifically stated some examples. The purpose wasn't to list them all.

Mirage OS has the problem that it still relies on Xen, so sometimes listing it gives argumentation power to those disregarding the dependency as a convenience, rather than lack of support on OCaml for such kind of programming.

Go's weird threaded runtime is nothing new. That is how Active Oberon tasks (aka Active Objects) are implemented.

I would guess that Go's tiny pauses would be less of a concern than it's overhead compared to C, C++ and Rust where there is more room for low level optimizations not available in Go.

Not particularly important, I'm just curious as to how much the GC is really responsible for slowness as opposed to just correlating with languages that don't allow controlling heap vs stack allocations.

MIT disagrees with both of you :

https://math.mit.edu/research/highschool/primes/materials/20...

I'm somewhat sad they didn't include a few things:

- a box/whisker plot in the latency comparison graph — esp. if we're to talk about Go's GC...

- some discussion/arguments why the particular C implementation was chosen ("tapip") — I'm not an expert in this area so I don't have the slightest idea how notable it is;

- how did they detect/measure the claimed memory leaks in C? also, some statistics about the claimed crashes?

- isn't clear to me if they used some "well known" load testing tools, or some homemade framework? (e.g. "siege" is a tool I read about more than once?)

- more details on how exactly the "correctness was determined by testing against Linux kernel [implementation]".

That said, my initial loose conclusions from this seem to be:

- it appears it may be easier to write a correct implementation in Go (the implementation seems to be written just ad hoc by the article authors?) than in C;

- it appears it may be easier in Go than in C to write an implementation scaling well w.r.t. average latency & throughput, assuming the need is for a multi-threaded & user-space implementation.

That paper was written by high school students; the only thing MIT about that paper is the hostname. It reads like a fun project but after skimming I would not consider it something authoritative on whether golang (or csp) is a better mechanism for writing a userspace network stack.

This is the same network stack (with a little bit of drift).

We intend to merge them into one repository soon. I am just a little disorganized.

Reply on news.ycombinator.com