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