Apparently it was good enough to inspire Go authors, and everyone that enjoys its influences in Go, as the ultimate design in language simplicity.
From the very start, Go was utterly practical, designed to be used for actual programming, and not PhD theses.
So compared to Oberon, Go had hash maps from the start. It didn't have the SCREAMING PROCEDURE/RECORD/VAR case-sensitive keywords, Go had multiple return values for error handling from the start, better namespacing support, variable declaration in-place, full support for UTF-8 for strings, etc.
And of course, Go has lightweight threads and channels, making it a great language for servers.
Except that Active Oberon from 1996, sorted out most of those cases.
Hash maps don't need to be built-ins, as proven in many languages.
Active Objects take care of lightweight threads and channels.
Oberon, the OS, was also good enough for Go's hero Rob Pike to implement ACME and RIO on the same UX principles, re-use Oberon-2 (yet another version you ignored) method syntax, and Oberon's SYSTEM package as unsafe.
Screaming keywords, only an issue when someone doesn't use an editor with automatic capitalization, only an issue for Notepad-like users.
> Hash maps don't need to be built-ins, as proven in many languages.
Except Oberon doesn't have generics.
From the very beginning, Go included very practical "magic" generic functions: append, len, cap, delete. Along with slices, they allowed Go to flourish without generics.
Oberon only has LENGTH.
> re-use Oberon-2 (yet another version you ignored) method syntax
Here's Go: "func (c Type) DoSomething(hello, world string) (int, error)". Here's Oberon: "PROCEDURE (c: Type) DoSomething(hello, world: STRING): INTEGER;" (error handling is for wimps).
It is similar, but not the same. Go also has structural polymorphism, which Oberon lacks.
> Screaming keywords, only an issue when someone doesn't use an editor with automatic capitalization, only an issue for Notepad-like users.
IT LOOKS UGLY, AND IT MATTERS A LOT, WHEN YOU MOSTLY READ THE CODE.
So yep, I maintain that Oberon is a shitty language. It might be useful as a starting point for new language design, but that's it.
It has never been practical, and on its own it only ever "succeeded" in the ETH where professors just forced students to use it.
What allowed Go to florish was being sponsored by Google, and being pushed alongside Docker and Kubernetes, without them, it would have had the same fate as Plan 9, Inferno and Limbo.
All really widely successfull commercial projects from UNIX folks. /s
Turns out shitty languages only flourish with the right sponsors.
Oberon-2 was in 91.
> What allowed Go to florish was being sponsored by Google
No. What allowed Go to flourish was a purely practical approach to the language, instead of theoretical nonsense.
For example, Oberon does not have ANY error handling.
> and being pushed alongside Docker and Kubernetes, without them, it would have had the same fate as Plan 9, Inferno and Limbo.
Facepalm. Docker was developed completely separately from Google.
Error handling in Oberon is as good as in Go, if error boilerplate all over the place.
Docker was originally developed in Python, and pivoted to Go because of Google.
Likewise Kubernetes started in Java, and pivoted to Go when some Go folks joined the team.
Had it not been for it, Go would have been as sucessful as Inferno/Limbo, which are highly inspired by Oberon, including its market failure.
...which could plausibly be fairly easily fixed by Zig's comptime feature, which would seem to fit the language very well.
And these keywords can be said to be "screaming" only by a person who does not understand what a "habbit" is. People get used to "screaming" keywords very quickly. And turns out, the uppercase keywords are more practical. Typing them does not take more time than typing curly braces all the time in other languges (you also need to press SHIFT for that, you know). The big keywords allow visual separation of syntax sections, that Go lacks so much. I.e. in Go, when you see a for-loop, it may not actually be a for-loop, but a while or a foreach loop -- to find out, you need to count the semicolons in the line.