3 ms·

Not to nitpick, but wouldn’t some of the same arguments against virtual functions apply to function pointers in C? The kernel uses a lot of “obj->obj_ops->foo(o

Not to nitpick, but wouldn’t some of the same arguments against virtual functions apply to function pointers in C? The kernel uses a lot of “obj->obj_ops->foo(obj, arg)” calls which are similarly dependent on the precise type of obj. In the case of these calls, the general assumption is that one can infer roughly what they _should_ be doing based on the type of obj. For example, if it was fd->fops->read(fd, buf, len) you would expect it to put some data in buf even if you had no idea what fd’s runtime type was. Your post also mentions operator overloading, which is a bit nastier since the calls aren’t explicit. But Rust also has operator overloading, so similar complaints would probably apply? In practice I’d expect the kernel to be fairly strict about limiting operator overloading (which would apply for both C++ hypothetically as well as Rust).

jerf 5y ago
If you look at it from the assembler point of view, even function pointer structs in C have a bound on them. I can't directly speak to Rust's overloading support. If it's still one static type lookup he may be ok with it, plus you have the clarity around ownership of any intervening constructions. I'm sure the Rust Evangelism Strike Force (awesome 80s cartoon music intensifies) will be along presently to answer the question of how much assembler one can generate with an overloaded operator. C++ really does have a particular ability to stack a huge number of abstractions into one little line. Ultimately it's a continuum rather than a sharp line, but C++ is really far on one side.
- pdimitar 5y ago
  > Rust Evangelism Strike Force I did get your point but would like to point out that using these slurs isn't helping any discussion. There are fanatics in every area everywhere. Their existence doesn't devalue any of the bigger groups they belong to. Their existence is a fact of life. I've worked with plenty of Rust devs (and I am an aspiring one myself although not all the way there yet) and I've only ever seen hard-working people with an excellent eye for detail and desire to maximally utilize the hardware and have better safety than other languages they worked with in the past. Zero fanatics.
- ncmncm 5y ago
  C++ and Rust both have a particular ability to integrate many abstractions in one place, all to be squeezed out by the compiler leaving exactly optimal object code for the specific uses in that specific place. Their ability to combine and particularize abstractions is a strength. Rust got it from C++ because it is so damned powerful. Just at the moment, C++ is notably better at this, in important cases, but I gather there are plans for Rust to adopt more of C++'s capabilities. The Rust designers fully understand the cases I mention, but are very busy.
steveklabnik 5y ago
Rust lets you choose between static and dynamic dispatch, and so operator overloading, 99.99% of the time, is statically dispatched, as that's the default.
- ncmncm 5y ago
  As is the case, in fact, in C++ code: so, a distinction without a difference. Linus's ignorant diatribe about C++ tells us plenty about Linus, but nothing meaningful about C++ or its suitability for kernel coding. That every detail he rails about in C++ applies equally to Rust is unintentionally revealing. That each such detail makes C++ and Rust better for large systems, moreso.
  - pdimitar 5y ago
    Perhaps his issue was previous C++ versions? Just a shot in the dark since I am not informed in detail.
    - oscargrouch 5y ago
      Yes, the famous post is old, if i recall correctly is from 2004, so its addressed to the C++ 98 and style that was in vogue back then. Take some vintage C++ code from late nineties, like games, and there's no concept of ownership, before smart pointers and move, and full of global's everywhere. It was also when code were transitioning for a multi-threading era, so using the same code style of the previous sequential era was really bad.
      - ncmncm 5y ago
        In 2004, template support in compilers in the wild (most particularly, MSVC) was still very shaky, so 1990s style C++ was common. Virtual functions are almost a curiosity today because we got better things for most uses. But everything he complained of is still there, and still sometimes the right thing. That his opinion didn't change as the facts changed under him reveals much, unless his public acceptance of identically the same features in Rust is meant to count as a sort of mea culpa. (To actually say so would be gracious.) Of course, all the new features C++ gained since '98 only make the language more useful for coding large, long-lived systems, as is amply demonstrated in the tens or hundreds of billions of lines of C++ code implementing exactly those systems. Rust's adoption of so many of those same features increases its usefulness for a growing number of those same purposes.

jerf 5y ago

If you look at it from the assembler point of view, even function pointer structs in C have a bound on them. I can't directly speak to Rust's overloading support. If it's still one static type lookup he may be ok with it, plus you have the clarity around ownership of any intervening constructions. I'm sure the Rust Evangelism Strike Force (awesome 80s cartoon music intensifies) will be along presently to answer the question of how much assembler one can generate with an overloaded operator. C++ really does have a particular ability to stack a huge number of abstractions into one little line. Ultimately it's a continuum rather than a sharp line, but C++ is really far on one side.

pdimitar 5y ago
> Rust Evangelism Strike Force I did get your point but would like to point out that using these slurs isn't helping any discussion. There are fanatics in every area everywhere. Their existence doesn't devalue any of the bigger groups they belong to. Their existence is a fact of life. I've worked with plenty of Rust devs (and I am an aspiring one myself although not all the way there yet) and I've only ever seen hard-working people with an excellent eye for detail and desire to maximally utilize the hardware and have better safety than other languages they worked with in the past. Zero fanatics.
ncmncm 5y ago
C++ and Rust both have a particular ability to integrate many abstractions in one place, all to be squeezed out by the compiler leaving exactly optimal object code for the specific uses in that specific place. Their ability to combine and particularize abstractions is a strength. Rust got it from C++ because it is so damned powerful. Just at the moment, C++ is notably better at this, in important cases, but I gather there are plans for Rust to adopt more of C++'s capabilities. The Rust designers fully understand the cases I mention, but are very busy.

steveklabnik 5y ago

Rust lets you choose between static and dynamic dispatch, and so operator overloading, 99.99% of the time, is statically dispatched, as that's the default.

ncmncm 5y ago
As is the case, in fact, in C++ code: so, a distinction without a difference. Linus's ignorant diatribe about C++ tells us plenty about Linus, but nothing meaningful about C++ or its suitability for kernel coding. That every detail he rails about in C++ applies equally to Rust is unintentionally revealing. That each such detail makes C++ and Rust better for large systems, moreso.
- pdimitar 5y ago
  Perhaps his issue was previous C++ versions? Just a shot in the dark since I am not informed in detail.
  - oscargrouch 5y ago
    Yes, the famous post is old, if i recall correctly is from 2004, so its addressed to the C++ 98 and style that was in vogue back then. Take some vintage C++ code from late nineties, like games, and there's no concept of ownership, before smart pointers and move, and full of global's everywhere. It was also when code were transitioning for a multi-threading era, so using the same code style of the previous sequential era was really bad.
    - ncmncm 5y ago
      In 2004, template support in compilers in the wild (most particularly, MSVC) was still very shaky, so 1990s style C++ was common. Virtual functions are almost a curiosity today because we got better things for most uses. But everything he complained of is still there, and still sometimes the right thing. That his opinion didn't change as the facts changed under him reveals much, unless his public acceptance of identically the same features in Rust is meant to count as a sort of mea culpa. (To actually say so would be gracious.) Of course, all the new features C++ gained since '98 only make the language more useful for coding large, long-lived systems, as is amply demonstrated in the tens or hundreds of billions of lines of C++ code implementing exactly those systems. Rust's adoption of so many of those same features increases its usefulness for a growing number of those same purposes.