Needs more context. It's more mature for some things than others, like many young languages.
> how are compile times
Not Go, for sure, but not the worst either.
> how much of a priority are they
Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is coming, you can try its initial implementation on nightly today. There's a lot more to do, but users really want improvements, so it is and will continue to be actively worked on.
Good to hear, when that is in place compile times matter a whole lot less
I never get the compile time argument. Well I code a big Scala application and the most time it spents is integration testing. the 10 minute test suite would probably still run 9 minutes and 30 seconds on go. we heavily rely on the database and cover a lot of concurrency/parallelism things in our tests. some things which we would need to test in go, too.
the compile time argument always looks good on first, but later on it's just a dumb way to prefer a language since it never matters. (Actually even the go maintainers didn't cared for a while about the compiler performance).
It's great to be able to compile applications like kubernetes in 2 minutes.
On the contrary, you haven't pointed out an objective issue that you have with Go. You offered some harsh remarks about the language but backed them up with praise.
I'd say you love the language, but apologetically so. You shouldn't it's a great language.
If ever you decide it's not for you then look at other alternatives, rust being one them.
I just think for me it absolutely shines for certain use-cases and sucks for many others, where I simply won't use it. The question then becomes "why Rust over [Haskell&friends]", not "why Rust over Go" ;)
But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all development at all, but there are select cases where I currently absolutely wouldn't use anything else) as these are those few programs where I really want to write (and later, read) exactly step-by-step "almost machine instructions" and where the only "expressiveness" needed is already fully afforded by Go and quite well at that. Dev-related mostly bulk-file-processing-based custom tooling (not bad to fire off sizable amounts of automatic background transformations from one weird format to another on file-system events etc.) .... filters through which to pipe vast/continuous data streams with just-some-processing over it .... providing out-of-process certain "low-level, must be lightning fast" tasks and logic with IPC for a higher-level codebase .... it's a great tool for such cases, especially given how simple the syntax is. Ie. the basics are grasped very easily very quickly and you don't have to recall "its pattern matching syntax and quirks, its generics syntax and quirks, its etc etc". =) I'm perplexed when teams choose to express their entire domain model or startup in Go, however.. fair game, maybe I'm missing something there