> What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists.

While that might be true in other contexts, the tools Oracle has been working on all work with the OCI standards. I actually completely disagree with creating a monoculture around a standard (that's how you get OpenSSL), and the whole reason why I contribute to the OCI standard is specifically so companies are free to create their own thing as long as users have the freedom to change between implementations (or write their own).

The situation right now is better than it was 3 years ago before the OCI existed and everyone was trying to make Docker fit their own usecases and needs.

> I really don't buy it that Go is a poor choice but that Rust isn't.

Take it from me [I'm a maintainer of runc], they're right. I would actually put it in far stronger terms than TFA, but Go has many problems that Rust does not. On the other hand, C/C++ have many problems that Go does not (which is why they went with Rust -- and I applaud them for it).

> These days Oracle is synonymous with vendor lock-in which is the antithesis of open source.

OCI is an open standard, anyone can contribute. Literally the precise opposite of vendor lock-in. I don't like Oracle either, but bashing them when they do something good is not helping.

> I really don't buy it that Go is a poor choice but that Rust isn't. If they had used C/C++, then the argument would sound more compelling.

It all boils down to Go's runtime implementation and their decisions regarding signal and threading handling.

It is because of these little things that Go isn't a fully systems language capable of replacing C and C++ for close to the hardware tasks.

For normal user space stuff sure, for kernel or low level tricks, if it requires more hand-written Assembly than C or C++ do, then it is a lost game trying to convince people to use it.

EDIT: Removed too many "level" typos

> These days Oracle is synonymous with vendor lock-in

It seems like their container builder, Smith, creates OCI [1] images, an open format that can be used from other tools such as runc or rkt.

[1] https://github.com/opencontainers/image-spec

> What sucks about open source these days is that companies keep reinventing the wheel with their own branding instead of helping improve the wheel that already exists.

Competition is a good thing overall, particularly when it is a corporation with a lot of resources putting some of them to creating an alternative. The alternatives to Docker have made them improve drastically. Uncharitably, this observation sounds like it's colored by your opinion of Oracle more than the structure itself: what if Google put out these three tools? I also strongly condemn a world where people are discouraged from exploring new approaches because something else, often something that a commenter happens to like, exists. Trust the market to speak.

> I really don't buy it that Go is a poor choice but that Rust isn't.

They're not selling it, WeaveWorks is, and the specific (legitimate) issue has been extensively debugged on go-nuts and elsewhere:

https://www.weave.works/blog/linux-namespaces-and-go-don-t-m...

It's dark corners of hardware and low-level APIs where Go suffers. Platform-heavy concepts in C often translate more readily to Rust than Go, but that's not a knock of any language -- just different targets. I've been down the syscall/C ABI/etc path in Go, and most of that stuff (oddly, given that the stdlib exercises it) feels bolted on to the language as an afterthought.

Rust, OTOH, intentionally sailed the "C But Better" tack. Interop between C and Rust is quite pleasant, and that is the gateway drug to all sorts of hardware-heavy tricks that really exercise a language. The same tricks in Go tend to surface weird stuff like the aforementioned issue.

That being said, generalizing to an indictment of Go as a language for this use case is flawed. That first sentence under Railcar could use some work.

Well put in every respect. As I mentioned in a couple other comments, that sentence could definitely be clearer.

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... ?

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

Sure, in that case, some Rust expert should write an article detailing all these Go pitfalls related to syscalls at kernel level :P

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.

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.

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.

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".

I meant specific to this issue given Oracle's wording in the post (and am not disagreeing with you).

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.