Maybe your container isn't set up right - Docker contains run directly on the host, just partitioned off from accessing stuff outside of themselves with the equivalent of chroot. Or it could be a Mac-specific thing. Docker only works that way on Linux, and has to emulate Linux on other platforms.

Why would I use docker? You don't have to use it. I'm just generating static binaries.

Does anyone understand how to do stuff without containers these days?

Because you just said:

> which is considerably faster than on docker

And we are curious why it is like so because we not only understand how to do stuff without containers, we also understand how containers work and your claim sounds off.

I don't understand what you are saying.

I'm saying it is slower on docker due to container startup, pulling images, overheads, working out what incantations to run, filesystem access, network weirdness, things talking to other things, configuration required, pull limits, API tokens, all sorts.

Versus "go run"

But usually it's not "considerably". Obviously setting up the container environment takes time but it should be well under a second per build.

Wow! You are right! Running go build on host instead of container is 1.16 times faster! A whopping 435ms difference! Amazing!

    /tmp/gitea $ hyperfine -p 'go clean -cache' 'make backend' 'docker run --rm -v $PWD:/build -v $HOME/.go:/go -w /build golang:1.22.3 make backend'
    Benchmark #1: make backend
      Time (mean ± σ):      2.766 s ±  0.021 s    [User: 8.429 s, System: 1.590 s]
      Range (min … max):    2.732 s …  2.800 s    10 runs

    Benchmark #2: docker run --rm -v $PWD:/build -v $HOME/.go:/go -w /build golang:1.22.3 make backend
      Time (mean ± σ):      3.201 s ±  0.034 s    [User: 9.9 ms, System: 7.7 ms]
      Range (min … max):    3.135 s …  3.235 s    10 runs

    Summary
      'make backend' ran
        1.16 ± 0.01 times faster than 'docker run --rm -v $PWD:/build -v $HOME/.go:/go -w /build golang:1.22.3 make backend'

(For incremental build, tested with `hyperfine --warmup 1 'make backend' 'docker run --rm -v $PWD:/build -v $HOME/.go:/go -v $HOME/.cache/go-build:/root/.cache/go-build -w /build golang:1.22.3 make backend'` it's 812.9 ms vs 1.146s.)

I’m using VMs these day because of conflicts and inconsistencies between tooling. But the VM is dedicated to one project and I set it up just like a real machine (GUI, browser, and stuff). No file sharing. It’s been a blast.

Right, they said they're on a macbook so unless they're going out of their way to run Linux bare-metal it has to use a VM. And AIUI there are extra footguns in that situation, especially that mapping volumes from the host is slower because instead of just telling the kernel to make the directory visible you have to actually share from the host to the VM.

See also: https://reece.tech/posts/osx-docker-performance/

See also: https://docs.docker.com/desktop/settings/mac/

> Shared folders are designed to allow application code to be edited on the host while being executed in containers. For non-code items such as cache directories or databases, the performance will be much better if they are stored in the Linux VM, using a data volume (named volume) or data container.

reminds me of https://world.hey.com/dhh/we-re-moving-continuous-integratio...

Yep.

And you usually get lumbered with some shitty thing like github actions which consumes one mortal full time to keep it working, goes down twice a month (yesterday wasn't it this week?), takes bloody forever to build anything and is impossible to debug.

Edit: and MORE YAML HELL!