Oberon has a tortured version history, so it takes a bit to explain what "Project Oberon 2013" is, but it's basically representative of Oberon in a very early stage of development.
This version was originally described by Wirth in his 1992 book "Project Oberon: The Design of an Operating System, a Compiler and a Computer". After his retirement he prepared a new edition, which came to be known as "Project Oberon 2013". For this edition he switched out the "computer" part -- the original used the now extremely obscure NS32000 CPU, the new edition used a custom RISC architecture implemented on an FPGA. But otherwise than this "implementation detail", the system was unchanged.
(And of course, given the FPGA source code, it's easy to build an emulator.)
But if you try this and it feels primitive -- it is. Later versions of Oberon got much fancier.
Oberon seems fascinating and I would like to eventually play around with it in an emulator, but any resources that show how it's being used (as opposed to a description of its design like in Wirth's book for example) would be appreciated.
Whats somewhat interesting is how structurally similar Oberon is to Go. One could say Go is Oberon dragged halfway towards C/Unix conventions (curly braces) with Go channels slapped on.
Rob Pike was aware of Wirth's work, as his ACME editor (https://en.wikipedia.org/wiki/Acme_(text_editor) ) took inspiration from it.
So either way, if there was inspiration for Go form Oberon or if there was not [a case of convergent evolution I guess in that case], it shows the strength of Wirth's thought.
It's just that Oberon is so generic that it looks literally like anything (e.g. pre-1.5 Java).
Go has several significant differences that made it far more useful:
1. Multiple return values for error handling. Its Oberon equivalent is bupkis. If you look at their examples, they just YOLO and print errors onto the console.
2. Multiple _returns_. The latest Oberon edition does not support early return from functions.
3. Structural polymorphism (objects automatically implement conforming interfaces).
4. Generics, and initially generic maps and slices.
5. Small neat language features like using the last component of the package path to refer to names.
There are minor similarities, mostly the fact that it is garbage collected, and also the receiver syntax Go inherited from Oberon-2 (i.e. proposed by Mössenböck, not by Wirth). Go has a completely different focus and is essentially a further development of Newsqueak, which was mostly influenced by Pascal and C.
That's pretty much it, for maybe 10+ years now. There was a successor project BlueBottle with some promise, but it did not deliver. Later it was renamed to A2. Surprisingly, it did not help.
https://en.wikipedia.org/wiki/A2_(operating_system)
IMO the authors of BB/A2 bet heavily on XML/Java hype, and were trying to make Oberon more like Java. The result was something without much internal consistency and not very usable.
Not being able to use a major browser and not having the resources to write one from scratch did not help either.
Then some of the major figures of this project left. And that was it.
There are some hobbyists and some small businesses which use it for niche projects and that is all
See https://github.com/rochus-keller/Oberon, and derived languages such as https://github.com/rochus-keller/Luon or https://github.com/rochus-keller/Micron, which inherit the "spirit of Oberon", but specialize for other use-cases than the original.
On a side note, there was also an AT&T Blit terminal emulator that also vanished.