krunvm is written in Rust, although it's not a simple container runtime -- it starts the container in a VM for isolation.

Personally I'd prefer people didn't use golang not because of speed but because it's a terrible programming language.

Maybe it's a little off topic here, but why would you consider Golang a terrible language?

Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine.

But once the code base grows, it easily becomes a tangled mess.

My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).

You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory.

In which directory to store files is an incredibly small and minor detail though.

In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily.

> In which directory to store files is an incredibly small and minor detail though.

Yeah it's a small detail, but it is important to me to not get lost in a directory tree.

Random example taken from a github search: https://github.com/gofiber/fiber

Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance?

For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works.

I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.