Well we can talk about this! > Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Apple did

Well we can talk about this! > Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Apple did have prerelease hardware that supported virtualization, which they supplied to Parallels. Docker has not worked with this hardware based on their press release and GitHub issue [1][2], although they may have received some specs. In any case, Docker depends on Golang with won't release until February. If Apple did make Docker a priority (which you'd expect given the namedrop at WWDC), this seems quite strange to me. [1]: https://www.docker.com/blog/apple-silicon-m1-chips-and-docker/ https://www.docker.com/blog/apple-silicon-m1-chips-and-docke... [2]: https://github.com/docker/for-mac/issues/4733 https://github.com/docker/for-mac/issues/4733 > Go isn't available because porting languages to a new processor is non-trivial. I'm sorry, I don't buy this at face value for Go and Rust. I believe these teams could support a new architecture very well very quickly with the right tools and support, like how their stuff also runs on weird things like S390. They show day in day out their stuff is very flexible. By no means do I want to suggest it's a trivial matter, but these toolchains are made to be portable and currently support both much more exotic and very similar systems to aarch64 macOS at the same time - like x86-64 macOS and arm64 iOS. Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI? It seems that if Rust and Go developers were approached with the right tools and support, they wouldn't have had to figure things out now. Is it that bad that they have to figure things out now? Not really - but I do think it could have been avoided, and we wouldn't have had to wait for a golang release in February and a Docker release after that.