4 ms·

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems langu

by braveo 10y ago

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.

bryanlarsen 10y ago
I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.
- braveo 10y ago
  the idea of cost-free came from C++ where the belief is that you don't pay for what you don't use. The underlying meaning there is that you don't pay the cost of virtualized function calls if you're not using polymorphism (this is a big reason why C++ doesn't feature virtualized function calls by default). polymorphism is of course an abstraction, the idea of cost-free is that you only pay for the abstractions you actually use. This is not the same as maximizing performance. The real question is whether or not you can do these things without giving the developer the control to maximize performance, and I think the answer is going to be no. The response will be that it's "good enough", but that's not actionable as we don't know what "good enough" means for any particular project.
Manishearth 10y ago
> If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.
- braveo 10y ago
  I find that unfair. C++ has new as well as other mechanisms such as perfect forwarding into smart objects, but no one seems to think C++ qualifies for the "you can do systems programming without malloc and pointers"? You can't do systems programming without them, what you can do is minimize their use by building abstractions, which other languages, such as C++ and D, already do. So this idea that people somehow think you have to use the actual malloc call throughout your code is a bit of a strawman.
  - Manishearth 10y ago
    I do think that C++ qualifies for that. I don't think there is widespread use of this yet -- I'm talking about the vast majority of "systems" code in C or C++ -- most of it is older and doesn't tend to use abstractions, or has been written from a "C with goodies" perspective. So yeah, (modern) C++ also contests this claim too. Rust contests a stronger claim about safety as well. ------ You're the one who said that "it's claimed to be a systems level language, and if it's really that painful to do systems level things," -- my point is that in both Rust and C++, "systems level things" don't need to involve pointer arithmetic and other similar things. They should be niche tools you reach for when the abstractions fail you, and the abstractions should not fail you that often. This is already true for both languages, I feel. It's not "niche" in C++ because the ecosystem needs time to evolve to that point, but for new code it probably works out.
    - 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.
      - 10y ago

by braveo 10y ago

bryanlarsen 10y ago

I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.

braveo 10y ago
the idea of cost-free came from C++ where the belief is that you don't pay for what you don't use. The underlying meaning there is that you don't pay the cost of virtualized function calls if you're not using polymorphism (this is a big reason why C++ doesn't feature virtualized function calls by default). polymorphism is of course an abstraction, the idea of cost-free is that you only pay for the abstractions you actually use. This is not the same as maximizing performance. The real question is whether or not you can do these things without giving the developer the control to maximize performance, and I think the answer is going to be no. The response will be that it's "good enough", but that's not actionable as we don't know what "good enough" means for any particular project.

Manishearth 10y ago

> If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.

braveo 10y ago
I find that unfair. C++ has new as well as other mechanisms such as perfect forwarding into smart objects, but no one seems to think C++ qualifies for the "you can do systems programming without malloc and pointers"? You can't do systems programming without them, what you can do is minimize their use by building abstractions, which other languages, such as C++ and D, already do. So this idea that people somehow think you have to use the actual malloc call throughout your code is a bit of a strawman.
- Manishearth 10y ago
  I do think that C++ qualifies for that. I don't think there is widespread use of this yet -- I'm talking about the vast majority of "systems" code in C or C++ -- most of it is older and doesn't tend to use abstractions, or has been written from a "C with goodies" perspective. So yeah, (modern) C++ also contests this claim too. Rust contests a stronger claim about safety as well. ------ You're the one who said that "it's claimed to be a systems level language, and if it's really that painful to do systems level things," -- my point is that in both Rust and C++, "systems level things" don't need to involve pointer arithmetic and other similar things. They should be niche tools you reach for when the abstractions fail you, and the abstractions should not fail you that often. This is already true for both languages, I feel. It's not "niche" in C++ because the ecosystem needs time to evolve to that point, but for new code it probably works out.
  - 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.
    - 10y ago