>C was also king of the zero cost abstractions.

C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping.

>C sure is not afraid to be complicated.

Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer.

C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?)

>I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project).

Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them.

>C, C++, Rust are all in that corner. > >Go obviously isn't.

Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ.

Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.

> Go obviously isn't.

You can use atomics and syscalls and even assembly in Go to have complete control over the system in the same way that you can in C/C++. It's definitely not trivial to bypass Go's memory model and get raw access to memory, but you can do it if you want. I'd say that Go discourages you from doing so, just the way Rust discourages the use of unsafe memory access even though you can if you want.

> C was also king of the zero cost abstractions.

Seriously? That's news to me. Only C zero cost abstractions I know of are based on external code generators. Or some macro abuse, but that's rather limited way to create abstractions.

But then again, when you really need to understand everything that is going on, abstractions are often not helping you.

(I write kernel drivers and bare bones embedded, where memory measured in kilobytes, not megabytes.)

JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future.

IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.

While Lisp is usually associated with FP practices, the CLOS (Common Lisp Object System) really helped me with getting OOP to click as a concept. Part of it is that, CLOS is just Lisp, so all of the concepts of OO programming are there with none of the syntax generally added in other OO languages. Also, the method/function names clearly name all the concepts instead of using opaque notation: SLOT-VALUE instead of dot, arrow, or double-colon notation, DEFCLASS does what it says on the tin instead of the vaguer "class ClassName { }" of C++/Java/etc. I feel like this makes it clearer what is happening. A good overview of CLOS is chapters 16 and 17 of /Practical Common Lisp/ (http://www.gigamonkeys.com/book/)

I've heard other people speak similarly of learning Perl's MOOSE after already being familiar with non-OO Perl. This probably is no coincidence since MOOSE is heavily inspired by CLOS.

I'm being very serious here, with no sarcasm: Using a language that has an alternate model of OO that either simply doesn't have inheritance, or makes it relatively hard.

IMHO it doesn't matter much how much you read about the differences, until you get in there it won't do much good. This is a good place to have a throwaway project on hand, because your first try is likely to be a very big mess.

If you know an inheritance model and a non-inheritance model, you'll be well on your way to understanding the nuances because you'll have the experience in the field.

(For reference, my personal definition of OO is pretty much any language where you can write object.method(arguments), some kind of polymorphism is made available on that, and that is either the primary or a very important element of design in the language. It's a very expansive definition because I find that having massive definition debates about what OO is to be nothing more than useless flamewars.)

Object Thinking, by David West for the essential ideas and philosophy of sane OOP.