Not really, I belong to those dreamers of systems programming languages with automatic memory management support.
Even though I don't really like most of Go's design decisions, I appreciate it can perfectly fine being used as C replacement, regardless of that anti-GC/RC folks say about it.
Perhaps a somewhat off-topic question but I'm early in my career and have found Go to be a rather pleasant language to work with so I'm really curious.
For example when I was working in a large microservice system, some of the java/typescript repos were a pain to work in because some of the developers had written crazy-looking oneliners. I mean it's possible to write difficult-to-read Go code as well, but I wasn't seeing it anywhere near as much.
Not the GP, but the error handling mechanism for one. You are less likely to silently/accidentally drop an exception vs Go's tuple return values. Thankfully, there’s linters for Go to catch some common mistakes, still feels fragile imho.
My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.
You could imagine a language which discourages bubbling exceptions by forcing you to catch and either handle or rethrow each possible exception -- while still making it hard to accidentally forget to handle an exception.
Certainly, and go already comes pretty close that explicitness via returned errors. At that point, we are down to a style choice between exceptions and error returns.
Honestly I'm not sure it matters and depends upon other factors being balanced in the ergonomics of the language. I don't see any reason why you couldn't accomplish the objective in either style of language.
My point is that Go today, both as matter of language features and how it tends to be used via communal norms, incentivizes explicit error handling. The parent comment stated, "You are less likely to silently/accidentally drop an exception vs Go's tuple return values" and while I could easily imagine language features that discourage bubbling exceptions ... in practice, I think that tends to be more the norm than explicit handling of tuple returns.
In my experience go developers have no clue about signals, the concept that you shouldn't output colours when piped to a file, and a number of other things.
It's all possible to do, but the practitioners don't know how.
Plenty of people on the Internet, as for the meaning of systems, that is your interpretation.
In the 1980's writing a compiler and linker would be considered systems as in operating systems, as it would targeting bare metal workloads, all of which available in Go today, via the way it is bootstrapped, gccgo, TinyGo and TamaGO.
I guess Go is a systems programming language after all.