Three New Open Source Container Utilities

In fact, everyone going after Oracle in this thread should do exactly that right now.

MS SQL Server is the only one that can compete with PL/SQL, the feature lists, and the GUI tooling provided out of the box for database administration, report generation and data modeling.

Java, they have made quite a few improvements to the language and runtime, some of them even unthinkable under Sun's stewardship, namely adding Graal to the official JDK and adding AOT support (most commercial JDK have it since early days of Java).

Also their roadmap for value types, GPGPU, fully replacing Hotspot with Graal and eventually having OpenJDK mostly implemented in Java, after those changes are done.

They created SPARC M7 with Silicon Secured Memory, as yet another band-aid against C security exploits.

So while the company might be heavy profit oriented, it is no different than any other corporation that likes money.

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.

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.

https://news.ycombinator.com/item?id=14479284

1: provide an alternative implementation of the oci-runtime so that the spec doesn't become too locked to a single implementation.

2: provide an implementation in a single language without some of the "baggage" of the existing implentations so that it is easy and fun to hack on.

3: experiment with new ideas to inform the future of the oci-runtime spec.

[1] https://hackernoon.com/the-curious-case-of-pid-namespaces-1c...

edit: you might be interested in their article on "Building a Container Runtime in Rust" [1]

[1] https://blogs.oracle.com/developers/building-a-container-run...

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.

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

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

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.