One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.
But then you have to compromise on speed of generated code, poor support of windows, number of libraries and overall ecosystem, no ability to generate standalone executables and probably more but I tried OCaml only briefly so can't speak to all of its shortcomings.
OCaml optimizations are certainly better than Go compiler that hardly does inlining and only recently got some PGO support, and those that care about using LLVM or GCC backends have to compromise on fronteds that still don't do generics.
Go support on Windows is also not great, plugin package doesn't work, filesystem support assumes POSIX semantics, cgo requires installing mingw.
Some see it as a compromising on types, I don't. After some years writing Scala code, trying to come up with even better types each day, Go to me is not a compromise but a relief.
My love for types peaked when I was in my mid-40s, now that I'm 50+ I want simple things.
From my experience this simplicity is something you pay the price along the way - development is harder (a good typing gives you a lot of hints about functionality and puts bounds on developers on how to use it) and more error prone (less stuff gets caught by the type checker, instead you find it out in runtime).
Of course it is good to be reasonable - some people completely fly off into the FP world and instead of actually building working stuff they think all day about some clever abstraction and types to model it.
I'd call that disillusionment with bad type systems, which are indeed unnecessarily complex. We have yet to achieve a typing "nirvana", but we're getting closer IMO.
That is definitely true, but from the article it's the backend that takes time, not the frontend where the language itself resides. If you compile go from llvm, it maybe as long as rust.
Zig is moving away from LLVM. Its already has its own backend targeting debug builds for x86 and arm. ReleaseFast and ReleaseSmall is an entire different beast, but its going to be tackled eventually.
Minor correction: Go compiler used to be a modification of Plan9 C compiler, then a Go port of that modification but then it was completely rewritten as a SSA-based compiler so today it has almost nothing to do with the original Plan9 code.
I wonder why we do not split up compilation more - especially for web developer.
Rust does this a little with "check", C with "-O".
I want fast compilation for my dev cycle or for unit tests, I want slow compilation with optimizations, escape analysis, correctness etc. for production (the distinction between a compiler and linter is also not clear, some compiles do what linters do in other languages).
