The author makes some interesting points but unfortunately he loses credibility right in the first paragraph by claiming “there aren’t any high performance, high level languages, really being seriously developed”. But what about Go, D, and Rust? That’s quite a lot of languages being developed for exactly that purpose. Then he back-fills by going on to dismiss Go and D out of hand, because as becomes apparent soon afterward what he actually wants to do is talk about Rust.
I felt this hurt his credibility straight away and distracted from the points he made later on.
This article is really interesting (although I didn’t finish reading it either last time I started, in December, or this time) and has a lot of ideas that should be explored further.
One thing that isn’t mentioned, but I think is relevant to his “being forced – or at least heavily encouraged – into heap allocations because something happens to be a[n instance of a] class”, is that inline objects (“in-place storage” in Sebastian’s terminology) are almost never compatible with polymorphism. That is, if you have some object field:
Shape contents;
and you want that field to be polymorphic, i.e. an instance of any subtype of Shape rather than a literal instance of Shape, then you probably need to be able to store subtype-specific data associated with it. In this example, a Sphere might have x, y, z, r attributes, for example. If you want to be able to store those inline in a parent object, instead of in a hash table or a heap-allocated object you point to or something, then you need to allocate space for them. But how much space to allocate? Knowing that requires the compiler to inspect all the possible subtypes of Shape, which means they need to be available at compile-time (you can’t link in new ones later, from a shared library, say), and that creating a new one can increase the size of the code that includes it.
Or you can just declare that no such subtypes can exist, or that they can’t add fields. But that’s pretty far from the Smalltalk or Java object models. Golang does it, and I think it’s one of the most interesting things about Golang.
Or you can just decide that storing a subtype object in there is allowed, but will completely fuck your program up, which is what C++ does, in keeping with C++’s philosophy that any language feature with high program-up-fucking potential is a great idea.
But, basically, inline storage is incompatible with polymorphism, which is to say, with OO.
The author makes some interesting points but unfortunately he loses credibility right in the first paragraph by claiming “there aren’t any high performance, high level languages, really being seriously developed”. But what about Go, D, and Rust? That’s quite a lot of languages being developed for exactly that purpose. Then he back-fills by going on to dismiss Go and D out of hand, because as becomes apparent soon afterward what he actually wants to do is talk about Rust.
I felt this hurt his credibility straight away and distracted from the points he made later on.
This article is really interesting (although I didn’t finish reading it either last time I started, in December, or this time) and has a lot of ideas that should be explored further.
One thing that isn’t mentioned, but I think is relevant to his “being forced – or at least heavily encouraged – into heap allocations because something happens to be a[n instance of a] class”, is that inline objects (“in-place storage” in Sebastian’s terminology) are almost never compatible with polymorphism. That is, if you have some object field:
and you want that field to be polymorphic, i.e. an instance of any subtype of
Shaperather than a literal instance ofShape, then you probably need to be able to store subtype-specific data associated with it. In this example, aSpheremight havex, y, z, rattributes, for example. If you want to be able to store those inline in a parent object, instead of in a hash table or a heap-allocated object you point to or something, then you need to allocate space for them. But how much space to allocate? Knowing that requires the compiler to inspect all the possible subtypes ofShape, which means they need to be available at compile-time (you can’t link in new ones later, from a shared library, say), and that creating a new one can increase the size of the code that includes it.Or you can just declare that no such subtypes can exist, or that they can’t add fields. But that’s pretty far from the Smalltalk or Java object models. Golang does it, and I think it’s one of the most interesting things about Golang.
Or you can just decide that storing a subtype object in there is allowed, but will completely fuck your program up, which is what C++ does, in keeping with C++’s philosophy that any language feature with high program-up-fucking potential is a great idea.
But, basically, inline storage is incompatible with polymorphism, which is to say, with OO.
It’s also very difficult with parametric polymorphism, unless you do it the code generation way, which has its own set of tradeoffs.
You’re right, and that’s at least as important a point as what I said about ad-hoc polymorphism; thank you for pointing that out.