Writing compilers is mostly aided by having a robust type-system and elegant tooling for parsers and AST transformation and so on.

Writing a compiler requires computer science knowledge, requires thought.

Haskell I think is a perfect example. It is a language that is well suited for writing compilers, but also very well suited for building services, backend applications, really anything if your developers are of average intelligence.

Go, however, wants to optimize for developers who think a for loop is easier to understand than an applicative functor, who think that generics are unnecessarily complex.

If you're trying to build a language for "the lowest common denominator, the average googler", that's the opposite of building a language for compiler writers, so in that case building a language that can represent such a hard CS problem well is counter productive.

The ideal set of building blocks depends on the problem.

If the building blocks make it easy to write concurrent code (Go, Erlang), then it becomes easier to write a server. If they make it easy to represent "A or B or C" and pattern match on trees (ML-like languages), then it becomes easier to write a compiler.

Add to that: if you are trying to make an easy to onboard language, you want to look at how beginners use it, not experts. Someone writing a compiler for language X is certainly an expert in X.

To me, being able to represent "A or B or C" is a bare minimum of a type system.

For what it's worth, Dart's intended domain (client UI apps) is much farther from compilers than Go's intended domain (servers and "systems programming") but we write almost all of our tools and compilers in Dart.

Dart isn't always the best language for compilers (we have a lot of Visitor patterns floating around, which are always tedious), but it's plenty good enough and it keeps the whole team working in our own language eight hours a day, which I think is invaluable.

Also, it means that when we make our implementations or compilers faster, we get a compounding effect because our tools get faster too.

Dart evolved into a nice language with null-safety and exhaustive patterns.

Hopefully in Go 3, we could see these features added as well.