4 ms·

I transcribe the following: "Go is a poor choice of language for a container runtime," Abrams wrote in a blog post." Go is a great language, but for small syst

I transcribe the following: "Go is a poor choice of language for a container runtime," Abrams wrote in a blog post." Go is a great language, but for small system utilities that need tight control over threads and make a high volume of syscalls, there are better options." Is this true ?

sanatgersappa 9y ago
Not sure about that, but Oracle is a poor choice as a source of open source tools, given their history.
- joseluisq 9y ago
  Right, especially its famous MySQL "Community"...
- praneshp 9y ago
  The author was one of the heaviest early contributors on the Openstack project.
  - reitanqild 9y ago
    Sadly whatever open source work a person does while working for Oracle seems to be tainted by it: It might be successful but if the name Oracle shows up I am scared.
- Veratyr 9y ago
  How is this relevant to the question raised by the person you're replying to? You've raised an entirely different concern and ignored the question. Why did you post this as a reply rather than a top level comment?
solidsnack9000 9y ago
Abrams is the author of the Go Netlink library, and participates in an interesting conversation here: https://news.ycombinator.com/item?id=14470231 https://news.ycombinator.com/item?id=14470231 (as `vishvananda`, it's the top comment). Many of the things the commenters discuss there are intricate. It's a lot of people who've worked on container runtimes and the issues relate to the interaction of Go with POSIX process and thread semantics. Go is not really intended to have transparent, finely controlled integration with C systems stuff...while Rust is.
deleted 9y ago
[deleted]
jitl 9y ago
I recently came up against this when deciding on a language to implement a POSIX-api backed utility. Go does not have the fork(2) POSIX API. This makes it much more difficult to spawn a process with precise POSIX semantics. Another issue is that when a goroutine (a fiber running in an OS thread) makes a syscall that blocks, that goroutine might be un-scheduled and then later resumed on a different OS thread. If your syscall is one that operates on the call-in OS thread, this could cause poor results. I think there are some mitigation strategies, but these two issues make syscall programming frustrating in Go.
cyphar 9y ago
Absolutely. There was a recent thread about how Linux namespaces and Go really don't like each other. There are many more issues with Go. Maybe I should write a blog post about it. https://news.ycombinator.com/item?id=14479284 https://news.ycombinator.com/item?id=14479284
- joseluisq 9y ago
  I would be great if you could write a post about that!
vishvananda 9y ago
Author here. This hit hacker news in the middle of the night my time. I think the other replies already answered your question but it is worth mentioning that my point could have been worded better. Note that go works very well for other parts of the container system: docker client, docker daemon, containerd, kubernetes, etc. It is just the low-level namespace handling it has trouble with.

sanatgersappa 9y ago

Not sure about that, but Oracle is a poor choice as a source of open source tools, given their history.

joseluisq 9y ago
Right, especially its famous MySQL "Community"...
praneshp 9y ago
The author was one of the heaviest early contributors on the Openstack project.
- reitanqild 9y ago
  Sadly whatever open source work a person does while working for Oracle seems to be tainted by it: It might be successful but if the name Oracle shows up I am scared.
Veratyr 9y ago
How is this relevant to the question raised by the person you're replying to? You've raised an entirely different concern and ignored the question. Why did you post this as a reply rather than a top level comment?

solidsnack9000 9y ago

Abrams is the author of the Go Netlink library, and participates in an interesting conversation here: https://news.ycombinator.com/item?id=14470231 https://news.ycombinator.com/item?id=14470231 (as `vishvananda`, it's the top comment). Many of the things the commenters discuss there are intricate. It's a lot of people who've worked on container runtimes and the issues relate to the interaction of Go with POSIX process and thread semantics. Go is not really intended to have transparent, finely controlled integration with C systems stuff...while Rust is.

deleted 9y ago

[deleted]

jitl 9y ago

I recently came up against this when deciding on a language to implement a POSIX-api backed utility. Go does not have the fork(2) POSIX API. This makes it much more difficult to spawn a process with precise POSIX semantics. Another issue is that when a goroutine (a fiber running in an OS thread) makes a syscall that blocks, that goroutine might be un-scheduled and then later resumed on a different OS thread. If your syscall is one that operates on the call-in OS thread, this could cause poor results. I think there are some mitigation strategies, but these two issues make syscall programming frustrating in Go.

cyphar 9y ago

Absolutely. There was a recent thread about how Linux namespaces and Go really don't like each other. There are many more issues with Go. Maybe I should write a blog post about it. https://news.ycombinator.com/item?id=14479284 https://news.ycombinator.com/item?id=14479284

joseluisq 9y ago
I would be great if you could write a post about that!

vishvananda 9y ago

Author here. This hit hacker news in the middle of the night my time. I think the other replies already answered your question but it is worth mentioning that my point could have been worded better. Note that go works very well for other parts of the container system: docker client, docker daemon, containerd, kubernetes, etc. It is just the low-level namespace handling it has trouble with.