As strange as it may sound, UNIX folks were Oberon fans, hence why ACME in Plan 9 had a similar developer workflow as the whole Oberon UI, where clickable text is combined with dynamic UI actions.
Plan 9 failed short of using a userspace systems language as C's successor (see Alef[0]).
Plan 9's sucessor, Inferno, fixed this with Limbo [1], where C is only used for the kernel, disVM, and a couple of userspace libraries, everything else done in Limbo.
Go ends up being a mix of Limbo, Oberon-2 method syntax and SYSTEM package.
However one thing that both Limbo and Oberon based systems have, and Go misses out, in how the whole platform embraces dynamic linking to extend existing applications, and surface operations to the UI.
By the way, I advise wasting a couple of hours diving into Inferno and Limbo's manuals[2],
[0] - https://en.wikipedia.org/wiki/Alef_(programming_language)
I was a big Oberon fan[0], not so much for Go, because in mid-90's using Native Oberon was an eye opening experience, in the hardware we had available back then.
20 years later (at Go 1.0 time), not so much.
[0] - The whole linage, and still think Active Oberon is the best dialect (with AOS) that eventually came to be, after Oberon v1.0 from 1987.