The human psychology is intriguing. The more I see "... Zig ..." the stronger the urge to learn and build something with it becomes.
In practice, though, I've found that building things with languages I am familiar with is more enjoyable for me, personally.
A severe case of mimetic desire. I suspect a lot of devs suffer from it.
For languages that support cross-compiling e.g Golang, the Docker docs recommend cross-compiling natively and copying the resulting binary to the various platform images. binfmt_misc with QEMU is needed for languages that don't support that, or when you want to run a binary from the base image. For example, if you're building a x86 Docker image on ARM and you run `RUN apt install` in the Dockerfile, you're essentially running an x86 ELF on ARM, and that's where QEMU/binfmt_misc step in.
Context overload is definitely a problem with MCP, but its plug-and-play nature and discoverability are solid. Pasting a URL (or just using a button or other UX element) to link an MCP server presents a much lower barrier to entry than having the LLM run `cli-tool --help`, which assumes the CLI tool is already installed and the LLM has to know about it.
This is an interesting branding exercise. Presenting MCP as 'Apps' makes it sound more accessible, while tools and MCP server sound very technical. Add a demo with Expedia and Spotify and you have an MCP that's end-user ready.
A severe case of mimetic desire. I suspect a lot of devs suffer from it.