It uses remote dependencies. First compilation in a single-run environment will be very slow, there won't be second compilation. Go compiler is fast when you add the `-i` flag, without it it takes a couple of seconds to compile a few hundred lines, a few more minutes when you have to `go get` packages. Now, github goes down, your build is broken for that time.

Not sure what the "it" is in your first sentence, but allow me to address the rest of your points. "First compilation ... will be very slow": the go compiler is in fact quite fast, orders of magnitude faster than C++ or rust compilers. The fact that there's a noticeable pause when you want to compile thousands of files does not mean that its slow. "There won't be a second compilation": not for each top level tool, but there certainly could be shared packages that don't need to be recompiled. "Go compiler is fast when you add the `-i` flag", ok, do that then. "Now, github goes down, your build is broken": you only need to depend on external github references if you want always to build against the latest version of your referenced code. I can't imagine anyone interested in stability wants this. There are lots of options for vendoring your dependencies in tree.

> "Go compiler is fast when you add the `-i` flag", ok, do that then

Only useful when you have mutable environment, most build spaces don't have it because it's insecure. So it's useless for big projects with external dependencies, you HAVE TO download them on each and every build.

>your build is broken": you only need to depend on external github references

Go projects use not only github repos, there is gopkg, gitlab and some others which I don't remember. All of them must be online and works fast, any lag will delay whole build system, which in many cases is pipe-lined. I can't imagine anyone interested in stability wants this.

>Not sure what the "it" is in your first sentence, but allow me to address the rest of your points.

The project in linked repository.

go-coreutils is abandoned, and not POSIX compliant. It was meant to be a proof-of-concept, and it kind of was, in a negative way.

What was the problem?

I have no idea. I have been watching 5-6 similar Go projects (some with the same name) which lost interest (some stopped after first commit), tried to create their own versions of coreutils (incompatible), never saw adoption, testing, or support, and they all tanked.

Some would consider Go to not be as safe as Rust for example. But his argument still holds for POSIX compliance, it is a loveless task so it it gets done at snail's pace.

This doesn't seem to be more than a toy project [1]. Not to mention, it's GPL-licensed, so it's basically useless for OpenBSD [2].

[1] - https://github.com/ericlagergren/go-coreutils/blob/master/xx...

[2] - https://www.openbsd.org/policy.html C-f GPL

This project is very incomplete (most commands are not implemented) and didn't get a commit since almost 6 months.