4 ms·

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory-unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitations of 8/16-bit architectures and optimizers that were far more limited than they are now. For many of the older of us – before C/C++ took over much of the world – safe languages were the norm (with the exception of dynamic memory for languages without automatic memory management). So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. That tradeoff is not always attractive. It presupposes that any and all forms of automatic memory management are not an option. Not a modern incremental, generational garbage collector, not Swift-style ARC (where unnecessary RC updates are optimized away), not some of the various and sundry automatic memory management techniques that researchers have come with over the years (such as MLKit's regions). If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. Not only are the use cases where you need exactly Rust's value proposition relatively rare, the ongoing and often aggressive evangelism sucks up oxygen in the open source commons, so to speak, that could go towards alternative efforts.

ameliaquining 9y ago
That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. That said, plenty of applications can easily afford to pay the runtime cost of a tracing garbage collector and don't need to be using Rust. (You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.) In general I tend to think of Rust as a better replacement for C++, and useful for approximately the same use cases. I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. I don't think I count techniques that aren't available in any language less obscure than Cyclone.
- rbehrends 9y ago
  > That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. 1. Many embedded applications do not use dynamic memory at all. 2. The runtime cost of a tracing garbage collector is largely a red herring. In a well-designed imperative program, all the cost involved with GC should not typically exceed 10% or so and manual memory management can only avoid part of that. On top of that, Rust's fallback option for shared ownership (Rc<T> and Arc<T>) are very expensive and can be worse than tracing GC. As I noted elsewhere, Rust is a very poor option when you have to deal with shared ownership (such as with persistent data structures). 3. Tracing GC does raise genuine issues in other situations (stack scanning in a multi-language environment, for example), but it's not the only established automatic memory management technique. There's no reason why you can't have a compiler switch to change to a different implementation. 4. Conversely, tracing GC can also have advantages, such as avoiding fragmentation for long-running processes (assuming the GC supports compaction). > I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. There's nothing hackish about Swift's ARC. It's basically bog-standard reference counting, which has very well understood semantics, and then the compiler optimizes away reference count updates that aren't needed. The primary downside of the approach is that it can't handle cycles automatically, but then, neither can Rust. Other than that, it ticks off pretty much all the boxes that Rust does. > I don't think I count techniques that aren't available in any language less obscure than Cyclone. I'm not sure why, nor why you would tie it to languages. After all, MLKit is Standard ML, hardly a language more obscure than Cyclone; deferred reference counting was first implemented for Java (lots of memory management techniques have actually used Java as a testbed). > You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is. If you want to go into a more detailed discussion of Rust with respect to software engineering, then we'll also have to discuss the software engineering costs that Rust creates, and that becomes a fairly large topic.
naasking 9y ago
> So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. And zero runtime overhead. > If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. I think you underestimate the attractiveness of zero overhead abstractions.
- rbehrends 9y ago
  > And zero runtime overhead. Please show me an implementation of binary decision diagrams [1] (ideally multi-threaded) where Rust has zero runtime overhead. Rust has zero runtime overhead only in some cases. [1] https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram
  - naasking 9y ago
    I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. So are you suggesting that claim in such a context is false, citing BDDs as some example, or are you taking my claim to be more broad than the context warrants, and so are arguing a strawman?
    - rbehrends 9y ago
      > I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. And that's what I was referring to. BDDs inherently require Rc<T>/Arc<T> (as long as you want to be memory-safe, at least) and therefore incur significant overhead (reference counting is one of the most expensive forms of automatic memory management). I use BDDs as an example, because there's no way to work around the structural sharing, as it's a requirement for an implementation. In addition, aiming for zero-cost abstractions is hardly a Rust-only thing. That's more of a Java problem because it only has polymorphic methods and no value types. Outside functional languages, lack of zero-cost abstractions is not a particularly common issue.
      - 9y ago
vvanders 9y ago
> It presupposes that any and all forms of automatic memory management are not an option. You might not want to make that strong assertion without spending some time with the language. Rc/Arc exist or if you want to build a GC into Rust nothing is stopping that. You can break out unsafe and start hacking away, in fact that's what the arena allocator crates do today. The space where memory and performance matter has very few options, which is why you see those of us who spend time in that area excited about Rust.
- rbehrends 9y ago
  > You might not want to make that strong assertion without spending some time with the language. Rc/Arc exist or if you want to build a GC into Rust nothing is stopping that. You can break out unsafe and start hacking away, in fact that's what the arena allocator crates do today. You're misreading what I said. I didn't say that Rust doesn't have Rc<T>/Arc<T> (given that I explicitly mentioned it in other comments). My point was that in order for Rust's approach to memory management to be worthwhile, automatic memory management cannot be viable (or you get a much simpler way of ensuring memory safety). Rust also offering a limited form of automatic memory management does not change that. > The space where memory and performance matter has very few options, which is why you see those of us who spend time in that area excited about Rust. I did not deny that Rust is an interesting option if automatic memory management is not a viable approach.
  - lossolo 9y ago
    > I did not deny that Rust is an interesting option if automatic memory management is not a viable approach. I think this is the main niche in which Rust can compete, while of course rust community want to attract people with different backgrounds (eg pythonists, webdevelopers etc). It's like you say, if I don't need the performance or I am not memory constrained then I will just use GC'd language.

ameliaquining 9y ago

That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. That said, plenty of applications can easily afford to pay the runtime cost of a tracing garbage collector and don't need to be using Rust. (You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.) In general I tend to think of Rust as a better replacement for C++, and useful for approximately the same use cases. I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. I don't think I count techniques that aren't available in any language less obscure than Cyclone.

rbehrends 9y ago
> That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. 1. Many embedded applications do not use dynamic memory at all. 2. The runtime cost of a tracing garbage collector is largely a red herring. In a well-designed imperative program, all the cost involved with GC should not typically exceed 10% or so and manual memory management can only avoid part of that. On top of that, Rust's fallback option for shared ownership (Rc<T> and Arc<T>) are very expensive and can be worse than tracing GC. As I noted elsewhere, Rust is a very poor option when you have to deal with shared ownership (such as with persistent data structures). 3. Tracing GC does raise genuine issues in other situations (stack scanning in a multi-language environment, for example), but it's not the only established automatic memory management technique. There's no reason why you can't have a compiler switch to change to a different implementation. 4. Conversely, tracing GC can also have advantages, such as avoiding fragmentation for long-running processes (assuming the GC supports compaction). > I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. There's nothing hackish about Swift's ARC. It's basically bog-standard reference counting, which has very well understood semantics, and then the compiler optimizes away reference count updates that aren't needed. The primary downside of the approach is that it can't handle cycles automatically, but then, neither can Rust. Other than that, it ticks off pretty much all the boxes that Rust does. > I don't think I count techniques that aren't available in any language less obscure than Cyclone. I'm not sure why, nor why you would tie it to languages. After all, MLKit is Standard ML, hardly a language more obscure than Cyclone; deferred reference counting was first implemented for Java (lots of memory management techniques have actually used Java as a testbed). > You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is. If you want to go into a more detailed discussion of Rust with respect to software engineering, then we'll also have to discuss the software engineering costs that Rust creates, and that becomes a fairly large topic.

naasking 9y ago

> So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. And zero runtime overhead. > If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. I think you underestimate the attractiveness of zero overhead abstractions.

rbehrends 9y ago
> And zero runtime overhead. Please show me an implementation of binary decision diagrams [1] (ideally multi-threaded) where Rust has zero runtime overhead. Rust has zero runtime overhead only in some cases. [1] https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram
- naasking 9y ago
  I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. So are you suggesting that claim in such a context is false, citing BDDs as some example, or are you taking my claim to be more broad than the context warrants, and so are arguing a strawman?
  - rbehrends 9y ago
    > I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. And that's what I was referring to. BDDs inherently require Rc<T>/Arc<T> (as long as you want to be memory-safe, at least) and therefore incur significant overhead (reference counting is one of the most expensive forms of automatic memory management). I use BDDs as an example, because there's no way to work around the structural sharing, as it's a requirement for an implementation. In addition, aiming for zero-cost abstractions is hardly a Rust-only thing. That's more of a Java problem because it only has polymorphic methods and no value types. Outside functional languages, lack of zero-cost abstractions is not a particularly common issue.
    - 9y ago

vvanders 9y ago

> It presupposes that any and all forms of automatic memory management are not an option. You might not want to make that strong assertion without spending some time with the language. Rc/Arc exist or if you want to build a GC into Rust nothing is stopping that. You can break out unsafe and start hacking away, in fact that's what the arena allocator crates do today. The space where memory and performance matter has very few options, which is why you see those of us who spend time in that area excited about Rust.

rbehrends 9y ago
> You might not want to make that strong assertion without spending some time with the language. Rc/Arc exist or if you want to build a GC into Rust nothing is stopping that. You can break out unsafe and start hacking away, in fact that's what the arena allocator crates do today. You're misreading what I said. I didn't say that Rust doesn't have Rc<T>/Arc<T> (given that I explicitly mentioned it in other comments). My point was that in order for Rust's approach to memory management to be worthwhile, automatic memory management cannot be viable (or you get a much simpler way of ensuring memory safety). Rust also offering a limited form of automatic memory management does not change that. > The space where memory and performance matter has very few options, which is why you see those of us who spend time in that area excited about Rust. I did not deny that Rust is an interesting option if automatic memory management is not a viable approach.
- lossolo 9y ago
  > I did not deny that Rust is an interesting option if automatic memory management is not a viable approach. I think this is the main niche in which Rust can compete, while of course rust community want to attract people with different backgrounds (eg pythonists, webdevelopers etc). It's like you say, if I don't need the performance or I am not memory constrained then I will just use GC'd language.