At my employer we use a subset of C++ and we use Go. We have a process by which when you write code others have to review it and you need to have a review by someone who is an "expert" [0] in the language [1]. You become an "expert" by being ordained by a shadowy committee who reviews code you submit to the code repository. They look for knowledge of the core language, how this language is used within the company, the external and internal libraries, performance, testing, etc. There are many factors and if you demonstrate all of them you get marked as being this type of "expert."
Before I joined this company I had written code which was launched into production in the following languages: Java, PHP, C, C++, assembly (arm + x86), Python, JavaScript (browser + node), and a few more. I would consider myself about average in all of these. I did not write any golang.
After I joined my current job I obtained this "expert" bit for both C++ and Go. It took ~1.5 years to get the C++. It took ~3-5 months for Go.
You can actually see the first golang code I wrote (this was at home when I was experimenting with the language before convincing some team members we should rewrite some of our infra in go): https://github.com/gravypod/gitfs
It has all sorts of mistakes but I didn't read any guides. I just used https://cs.opensource.google to search for examples of things that I thought I would need to do (ex: "how do I do a switch statement").
For C++ I had worked on ~2 projects that used it. My first few PRs were very rough and I had a lot of performance issues that crept into my code. If I didn't already have a lot of C experience I would have also had a bunch of pointer/lifetime stuff the reviewers would have found (I know this from reviewing new team members first lines of C or C++).
I know that to some C++ represents a literal worst case but most people coming from C++ to Go will think it's amazing because it removes all of the common footguns.
> Things like awkward error handling
Yes, it is very clunky and annoying but it's very simple. It's just a normal if statement and doesn't use any special language rules. I think this would still be better if there was dedicated syntax for it (something like throw/try/catch which works the same way but gives it a different syntax) but honestly I don't think it's as bad as it's made out to be. It's basically a "less bad" errno and that worked go-... dece-... ehm fine for many years.
> dealing with null
I've never really had to think about this too much. There are some times it is important but I rarely return nullable things without errors and it hasn't bitten me yet. My code is not provably correct but for the things I'm working on I don't need that guarantee. If I did I'd probably switch to Rust or something with better type safety.
> capitalization for public/private
Yea, this sucks but it doesn't really get in my way much. I don't like it but it isn't actively hurting my usage.
> magic functions
Like `String()`? I don't know if that's the worst think in the world. Python, C++, and Java have things like this.
> and imports
It's not been too bad for me. What I think is unfortunate is that the package of something is unconnected to where it is in most go usages which is annoying but it makes things more terse. This does actually hamper my productivity.
> I don't think it's good or easy to use at all, but people rave about it.
It's pretty easy to use because all of the libraries I've seen share common interfaces for behavior. This makes things feel a lot more cohesive. fuse-go and billy was very easy to use in gitfs because of this.
[0] - This is not an expert as in "knows everything" but more like "has been seen to consistently write efficient, simple to understand, idiomatic code." It basically means that when someone else from this subset of SWEs reviews your code they often do not have many comments. Again, I want to stress, this is not expert as in "knows everything" just as in "good enough".
[1] - https://abseil.io/resources/swe-book/html/ch03.html#what_is_...
