6 ms·

It's true, but to affirm that "Go is a poor choice of language for a containers" it would be equivalent to say that Docker did a poor language choice... ?

jsmthrowaway 9y ago
Don't generalize from this post. That's a trap. Go's runtime model doesn't interact well with stateful namespace syscalls in the Linux kernel, and it's hard to fix. That's all that can be concluded.
- cyphar 9y ago
  We've had production issues where Go's memory model will cause programs such as dockerd to crash due to overzealous memory over-commitment (Go doesn't actually free memory they use MADV_DONTNEED). There are definitely problems with Go that go outside of "stateful namespace syscalls".
  - jsmthrowaway 9y ago
    I meant specific to this issue given Oracle's wording in the post (and am not disagreeing with you).
  - pjmlp 9y ago
    Go could be in the same space as Oberon was for systems programming (real OS stuff and bare metal coding), but for that to happen they would need to improve the runtime and unsafe package for those scenarios.
cyphar 9y ago
Docker didn't have much of a choice. At the time they had two options: C/C++ or Go (Rust wasn't usable at). They went with the right choice at the time, Go. Unfortunately nobody really knew about all of the pitfalls of Go (there are many upsides, but writing a container runtime in Go is definitely not one of them). Right now, I would definitely recommend people write things like this in Rust. In fact I was planning on working on something similar. :P
- joseluisq 9y ago
  Sure, in that case, some Rust expert should write an article detailing all these Go pitfalls related to syscalls at kernel level :P
  - cyphar 9y ago
    I'm not a Rust expert (yet) but I probably should write something up because this topic always comes up when people like me start complaining about Go.
vishvananda 9y ago
Author here. As I mentioned in another comment. I should have clarified that its shortcomings are specific to the container runtime (i.e. the part that creates and enters the namespaces). Go is a great choice for the command line utilities and daemons. I am a big fan of go in general, and even the container builder smith is written in go.

jsmthrowaway 9y ago

Don't generalize from this post. That's a trap. Go's runtime model doesn't interact well with stateful namespace syscalls in the Linux kernel, and it's hard to fix. That's all that can be concluded.

cyphar 9y ago
We've had production issues where Go's memory model will cause programs such as dockerd to crash due to overzealous memory over-commitment (Go doesn't actually free memory they use MADV_DONTNEED). There are definitely problems with Go that go outside of "stateful namespace syscalls".
- jsmthrowaway 9y ago
  I meant specific to this issue given Oracle's wording in the post (and am not disagreeing with you).
- pjmlp 9y ago
  Go could be in the same space as Oberon was for systems programming (real OS stuff and bare metal coding), but for that to happen they would need to improve the runtime and unsafe package for those scenarios.

cyphar 9y ago

Docker didn't have much of a choice. At the time they had two options: C/C++ or Go (Rust wasn't usable at). They went with the right choice at the time, Go. Unfortunately nobody really knew about all of the pitfalls of Go (there are many upsides, but writing a container runtime in Go is definitely not one of them). Right now, I would definitely recommend people write things like this in Rust. In fact I was planning on working on something similar. :P

joseluisq 9y ago
Sure, in that case, some Rust expert should write an article detailing all these Go pitfalls related to syscalls at kernel level :P
- cyphar 9y ago
  I'm not a Rust expert (yet) but I probably should write something up because this topic always comes up when people like me start complaining about Go.

vishvananda 9y ago

Author here. As I mentioned in another comment. I should have clarified that its shortcomings are specific to the container runtime (i.e. the part that creates and enters the namespaces). Go is a great choice for the command line utilities and daemons. I am a big fan of go in general, and even the container builder smith is written in go.