[Rochus]

Well, if you prefer Rust, Haskell or C++ then why don't you just use Rust, Haskell or C++? Languages like Go or Oberon are intentionally as simple as possible, which is their core benefit, not their weakness. That is precisely the advantage of the diversity of languages: you can choose the one that suits you best.

[pjmlp]

If Go 1.18 comes out as planned, for me it is good enough.

As for Oberon, while I enjoyed it, my real fun was with Active Oberon.

[Rochus]

Never used Active Oberon in a project, but I'm currently implementing an extended Oberon version I call Oberon+ (see https://github.com/rochus-keller/Oberon/blob/master/document...) which I enjoy using (currently migrating the Are-we-fast-yet benchmark suite, see https://github.com/rochus-keller/Oberon/tree/master/testcase...). It has generic modules and it is still simpler than Go.

[pjmlp]

Looks quite interesting, thanks for sharing.

Love the simplifications you did, and the generic modules is basically what I have advocated Go should have done, had they actually bothered to look into CLU and Modula-3.

[Rochus]

Thanks. Generic modules turned out to be a good fit for Oberon; I can even validate the generic modules before instantiation and even without type constraints; assumptions about types can be hidden using procedure types which is also a good fit for Oberon (I can still add type constraints later if really necessary). The concept is actually mostly inspired by Ada, including the explicit instantiation. It was the first approach I tried, then I switched to the Roe/Szyperski proposal for some time, but which turned out to cause to many complicated rules and consequences not in harmony with the Oberon philosophy, why I finally switched back to generic modules. The approach indeed has similarities with Modula-3, but the instantiation is simpler, and the generic parameters are types, not module interfaces.