Column – High-performance, columnar, in-memory store with bitmap indexing in Go

In ECS (where Components are a bag of data, and systems handle all logic/operations), and like a DB, the object is defined by an id and its relations; from the relations, you can derive available capabilities.

That is, an object tells you what it can do. In a DB, what it can do tells you the object.

You can create the same system with interfaces by simply ignoring the methods part of it, and keeping the data part, but associating data with capabilities is pretty much the defining difference between objects and structs.

More importantly from an architectural perspective, in ECS the logic isn’t associated with the object, it’s associated with a system that takes the object as input. The system is shared across all objects. The object (entity) for ECS is little more than an id and some relations.

An ECS very directly corresponds to an RDBMS. To call it OOP is to deny the ORM’s classic Object-Relational mismatch.

I didn't say it was. The key par was "state is managed seperately from logic."

> Component programming with interface separated from state

There is no such things as interfaces in ECS. Interfaces are a way of describing how state is bundled with logic. ECS does not do that.

> Those that promote ECS as not being OOP 99% of the times never read books like the one I linked on my comment.

I'll admit that I have not read that book. Your condescending appeal to authority here doesn't actually promote conversation.

Please, tell me what the "objects" are in ECS or what else qualifies it as OOP?

Docker helps manage all of this, and does it fairly quickly, and made life relatively easy, but not without a cost in time and complexity.

Go, out of the box, produces statically linked machine runnable binaries, including embedded resources, so you get the equivalent of an uberjar, plus resources, plus the runtime, all in a single executable file. And all of this pops out in a second or two with `go build`.

AOT for Java might perhaps have similar advantages except that AFAIK (two years ago) the AOT compilers were expensive and had plenty of caveats with eg reflection. I expect they would be even slower than javac as well. So certainly a solution, and maybe you don’t need docker any more, but then you have a different set of problems. It was never feasible when I was doing Java.

To be clear, this isn’t a Java vs Go thing. The question was why don’t Go devs use Docker, and I’ve given some reasons. I quite like the Java language and miss some aspects of it, but there is a lot about the Java environment that I don’t miss and runtime deployment complexity is one of them.