5 ms·

like I said, that's a strawman. C++ has had new/new[]/auto_ptr since C++ 98, so almost 20 years. The ideas of smart pointers have been around for a really lon

by braveo 10y ago

like I said, that's a strawman. C++ has had new/new[]/auto_ptr since C++ 98, so almost 20 years. The ideas of smart pointers have been around for a really long time as well. Then there's the C constructor convention through opaque void pointers idiom. This stuff is not new, not even close to new, NO ONE, not even the kernel developers, would make the argument that you cannot build abstractions around malloc. If that's really what you're arguing, well you're not saying anything that C developers don't already practice.

Manishearth 10y ago
When I say "malloc", I'm including `new` -- programming patterns that use new/delete are the same with malloc/free. new/delete doesn't really change the programming pattern, it just has a slightly nicer API. smart pointers have been around for a while too. I see some codebases using them. But many don't. > NO ONE, not even the kernel developers, would make the argument that you cannot build abstractions around malloc. I never said that kernel devs or whatever would make that argument. ---------------- Look, you seem to think I've said something different than what I did here. You said "if it's really that painful to do systems level things, then there's a problem somewhere.". I'm saying that Rust contests the claim that malloc/new/whatever must be easy to use for systems level things. Easy-to-use abstractions around them work well too. It's not that C++ doesn't have these abstractions, it does, and has for a while. My statement isn't one against C++. My point is that the difficulty of using programming paradigms designed around malloc/new should not be a dealbreaker for a systems language, provided that the same tasks can be accomplished without raw allocation using a suitably generic abstraction. C certainly promotes malloc-based-paradigms. C++ has good alternatives, but a lot of the lower-level stuff I find avoids them because ultimately malloc/new aren't hard in C++. Rust makes them harder to use, but provides sufficient abstractions/abstraction-building-power that this should not be an impedance to systems programming. And, again, I'm not saying C++ doesn't -- I'm just saying that C++ also makes it easy to use malloc/new-based patterns, so you will continue to see those in systems programs even if they aren't necessary. Now, interestingly, an abstraction for a vec-with-header doesn't actually seem to exist in the crate ecosystem, probably because folks don't like unconditional allocation. But it's relatively easy to build, might do it over the weekend. (You can fake it in safe code using DSTs but it's not so great)
- braveo 10y ago
  new/new[], delete/delete[] are abstractions around *alloc/free. That's not really under discussion, that's what they are. So when you talk about the ability to build abstractions around malloc, you're also talking about these operators in C++. You may not like that they tend to be very thin abstractions, but they are abstractions, and the point is that the idea of building abstractions around malloc isn't new and certainly isn't unique. You said: >> You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. While in defense of the statement: >> Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. This is presented as something unique to rust, which isn't even close to the accurate. This is why I called it a strawman. No one, not even kernel developers using C, are incapable of building abstractions around malloc to make it easier/safer to use. The rest of what you say is inconsequential in my opinion. This isn't about C++, this is about your implication that building abstractions around malloc is something new or novel about Rust. It isn't. Not even the idea of safety around malloc is new, new[]/delete[] are themselves abstractions intended to make it less error prone to create/destroy contiguous blocks of memory. That doesn't even get into the smart objects and RAII which have been around for a very very long time in C++. None of this is new to Rust, and I think it's a bit disingenuous to imply that it is.
  - Manishearth 10y ago
    > So when you talk about the ability to build abstractions around malloc, you're also talking about these operators in C++. Right, I wasn't talking about just that, I was specifically referring to abstractions that make you change your programming patterns. C++ has those too (the move-based abstractions), but I don't consider new/delete to be them. My point was sort of "being able to write code that looks like this is not necessary for systems programming". Being able to do the task at hand is, but it need not be done using code like that. > This is presented as something unique to rust, which isn't even close to the accurate. Fair. It's not. I didn't intend to mean that. I'm sorry. I was a C++ programmer for a quite a while, some of which time I used modern C++, so I'm quite aware that these abstractions are not unique to Rust. The reason I phrased it that way is that C++ doesn't really make it harder to use direct-malloc-based (or raw-pointers-with-new) programming, and most of the lower-level C++ code I've seen (this is anecdotal) still uses this. So C++ doesn't contest the claim the same way Rust does (it does contest the claim though), since Rust codebases doing the same thing (even the kernels in Rust) tend to move strongly in the direction of avoiding unsafe pointer twiddling as much as it can. This is a bit more nuanced (and based on anecdotal evidence on low level codebases I've seen) than I really wrote in my original comment, and I apologize for that.

by braveo 10y ago

Manishearth 10y ago

When I say "malloc", I'm including `new` -- programming patterns that use new/delete are the same with malloc/free. new/delete doesn't really change the programming pattern, it just has a slightly nicer API. smart pointers have been around for a while too. I see some codebases using them. But many don't. > NO ONE, not even the kernel developers, would make the argument that you cannot build abstractions around malloc. I never said that kernel devs or whatever would make that argument. ---------------- Look, you seem to think I've said something different than what I did here. You said "if it's really that painful to do systems level things, then there's a problem somewhere.". I'm saying that Rust contests the claim that malloc/new/whatever must be easy to use for systems level things. Easy-to-use abstractions around them work well too. It's not that C++ doesn't have these abstractions, it does, and has for a while. My statement isn't one against C++. My point is that the difficulty of using programming paradigms designed around malloc/new should not be a dealbreaker for a systems language, provided that the same tasks can be accomplished without raw allocation using a suitably generic abstraction. C certainly promotes malloc-based-paradigms. C++ has good alternatives, but a lot of the lower-level stuff I find avoids them because ultimately malloc/new aren't hard in C++. Rust makes them harder to use, but provides sufficient abstractions/abstraction-building-power that this should not be an impedance to systems programming. And, again, I'm not saying C++ doesn't -- I'm just saying that C++ also makes it easy to use malloc/new-based patterns, so you will continue to see those in systems programs even if they aren't necessary. Now, interestingly, an abstraction for a vec-with-header doesn't actually seem to exist in the crate ecosystem, probably because folks don't like unconditional allocation. But it's relatively easy to build, might do it over the weekend. (You can fake it in safe code using DSTs but it's not so great)

braveo 10y ago
new/new[], delete/delete[] are abstractions around *alloc/free. That's not really under discussion, that's what they are. So when you talk about the ability to build abstractions around malloc, you're also talking about these operators in C++. You may not like that they tend to be very thin abstractions, but they are abstractions, and the point is that the idea of building abstractions around malloc isn't new and certainly isn't unique. You said: >> You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. While in defense of the statement: >> Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. This is presented as something unique to rust, which isn't even close to the accurate. This is why I called it a strawman. No one, not even kernel developers using C, are incapable of building abstractions around malloc to make it easier/safer to use. The rest of what you say is inconsequential in my opinion. This isn't about C++, this is about your implication that building abstractions around malloc is something new or novel about Rust. It isn't. Not even the idea of safety around malloc is new, new[]/delete[] are themselves abstractions intended to make it less error prone to create/destroy contiguous blocks of memory. That doesn't even get into the smart objects and RAII which have been around for a very very long time in C++. None of this is new to Rust, and I think it's a bit disingenuous to imply that it is.
- Manishearth 10y ago
  > So when you talk about the ability to build abstractions around malloc, you're also talking about these operators in C++. Right, I wasn't talking about just that, I was specifically referring to abstractions that make you change your programming patterns. C++ has those too (the move-based abstractions), but I don't consider new/delete to be them. My point was sort of "being able to write code that looks like this is not necessary for systems programming". Being able to do the task at hand is, but it need not be done using code like that. > This is presented as something unique to rust, which isn't even close to the accurate. Fair. It's not. I didn't intend to mean that. I'm sorry. I was a C++ programmer for a quite a while, some of which time I used modern C++, so I'm quite aware that these abstractions are not unique to Rust. The reason I phrased it that way is that C++ doesn't really make it harder to use direct-malloc-based (or raw-pointers-with-new) programming, and most of the lower-level C++ code I've seen (this is anecdotal) still uses this. So C++ doesn't contest the claim the same way Rust does (it does contest the claim though), since Rust codebases doing the same thing (even the kernels in Rust) tend to move strongly in the direction of avoiding unsafe pointer twiddling as much as it can. This is a bit more nuanced (and based on anecdotal evidence on low level codebases I've seen) than I really wrote in my original comment, and I apologize for that.