OCaml compiles just as fast without having to compromise on the type system.

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.

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.

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 am almost 50, and my point of view on Go from 2012 has hardly changed.

http://lambda-the-ultimate.org/node/4554#comment-71504

At least it does generics now.

> At least it does generics now

Not in gccgo

Indeed, as you see on other remarks from me I am aware of it, my point was about the language as designed, not the implementations ecosystem.

TinyGo also doesn't do them.

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.

> using LLVM backends

Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

TinyGo.

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.

It’s not just Rust. Practically every compiler based on LLVM is slow. Swift, Zig, Clang.

The Go compiler being written from scratch based on the Plan9 C compiler is a huge advantage.

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 will chime in to day that rust is also building a alternative to the LLVM backend in the form of cranelift : https://github.com/rust-lang/rustc_codegen_cranelift

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.

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).

We do, you have profile configuration for dev or for release

You can get pretty big differences in terms of compile speed / binary size

Giving up entirely on the compile time of "performance" builds can be bad too though, e.g. for people writing games, audio software, etc.

Only if you need to test the full game. If you can unit test algorithms and learn something then fast builds matter.

second that. also another point: I write most Go code using only the stdlib, so there is no dependency web to take care on top of the actual code.

I also have much less dependencies with Go compared to other languages, especially in TS.