[mseepgood]

Wirth regretted it later and didn't add it to Oberon. Quote from "From Modula to Oberon":

"Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations (and subranges) had led to a type explosion that contributed not to program clarity but rather to verbosity. In connection with import and export, enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor."

[zoogeny]

> enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers

I am confused by this assertion. I mean, if I had a module `Source` defining an enum:

    type MyEnum = (value1, value2, value3, value4)

and another module wanted to import it:

    import ( MyEnum ) from "Source"

I don't see how I have automatically imported all of the associated constant identifiers. Unless he was assuming that this would force me to import `value1`, `value2`, etc. as distinct identifiers? But it seems these ought to be namespaced inside `MyEnum`, e.g.

    MyEnum.value1

And one could easily imagine an import syntax to selectively import Enum values if desired:

    import ( MyEnum: ( value1, value3 ) ) from "Source"

Of course, I'm just making up syntax, but I hope the meaning is clear.

[pjmlp]

I know, and there is a reason why my favourite descendant from Oberon is Active Oberon, and not what Wirth pursued after 1992.

Oberon-07 minimalism doesn't make Go better.

[mseepgood]

You can disagree with design philosophies, but Wirth and the Go designers probably have thought more about these things than you.

[pjmlp]

Appeal to authority.

Also note that none of Wirth's Oberon variants have achieved any commercial success.

Modula-2, which had enums, on the other hand did enjoy a limited success, across UNIX, PC and Amiga, and is nowadays even available as standard GCC fronted.

Go would have been a failure if the authors weren't Google employees, like it happened with their Limbo.

[Thaxll]

Dart is a really good example. A dead language but somehow it was created by Google, what gives?

[pjmlp]

Everyone giving this example keeps missing the part of Google politics, where the team lost the support from Chrome team, the language development was rescued by AdWords team that had just migrated from GWT into AngularDart before this occurred, key language designers like Gilad Bracha and Kasper Lund left Google, Angular migration to Typescript, leaving Dart only existence reason being powering AdWords until Flutter came to be.

Nowadays I would bet there are more people using Flutter/Dart than either Xamarin, Cordova or React Native on mobile apps.

Also anyone using JavaScript libraries like scss, is dependent on Dart, at least until they remember to rewrite it in Rust, as is now fashionable on JavaScript tooling ecosystem.