[on the Cforall team] FWIW, the Go docs are somewhat ambivalent on the OO nature of Go[1]. Along similar lines, our main objections to object-orientation are that, in "traditional" implementations like C++ or Java, it tightly couples a number of features that we believe would be better served by a more orthogonal design.

More specifically, C++-style OO couples (1) in-memory layout of types, (2) behaviour of objects, (3) encapsulation boundaries, and (4) the hierarchical "is-a" relationship. In Cforall, (1) and (3) are handled by the usual C mechanisms of struct types and translation-unit boundaries [we go to great effort to maintain C-style separate compilation, though we will likely build a better namespace/module system at some point], (2) by traits, and (4) by a yet-to-be-implemented system of RTTI for specific "inherited" types [likely when the undergrad RA who started our exceptions implementation comes back as a Master's student this fall].

As you mention, many use-cases (including widgets in GUIs, but also abstract syntax trees in compilers) require some sort of heterogeneous collection type to work properly, and for this OO is the right model. We just don't want to force the entirety of that model on every use case, so we can just take traits when we want to write a polymorphic function over related types or an ADT like "Set" which requires its keys be sortable, or just take RTTI for exception handling, when the set of exception types we're handling is known statically, but we need to determine if the thrown exception inherits from one of the caught types.

[1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language

Modern GUIs happen mostly in JavaScript with the react + redux ecosystem which is more of a functional model then OO.

JavaScript uses the same OOP model as SELF, prototype based.

It doesn't matter what libraries one uses, they don't remove the OOP model out of JavaScript.

Additionally all those react ideas already existed in Smalltalk as well.

I'm talking about javascript + react + redux. Generally when you use these 3 technologies you avoid javascript oop features.

No you don't, because JavaScript is OOP all the way down.

Yes you do, because immutability is recommended by redux. OOP features can be ignored.

Unless you manage to write JavaScript code without functions and data types, you are using JS OOP features, implemented via prototype based OOP.

No. I'm talking about programming style. I am not talking about how certain JavaScript properties are implemented.