Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> often leads to unnecessary copying [1].

Rust is very different from C++ here. You wouldn't get those copies unless you directly called .clone(), so you'd know you were doing a deep copy.



That's not the point that I'm getting at. Exclusive ownership invariably mandates copying for certain use cases. Rust allows you to obviate this in a few more cases through borrowing, but as a general rule, exclusive ownership and having multiple references to the same object do not mesh. You need to get rid of either one or the other. That Rust forces you to be explicit about copying in those cases does not make the underlying problem go away.

This is especially noticeable and constraining when you come from a functional programming background and not C++ or when you're doing stuff that's more complicated than shuffling bytes (I've mentioned binary decision diagrams as an example).

The bigger point is: as it is extremely rare for me to write one of the few niche applications that are actively GC-hostile (such as web browsers, AAA video games, or OS kernels), I don't see the point of jumping through all the extra hoops that avoiding GC brings with it.


> Exclusive ownership invariably mandates copying for certain use cases.

Hm, why would you not use multiple ownership then, instead?


> Hm, why would you not use multiple ownership then, instead?

That's exactly what I want. The problem is that (1) it comes with significant runtime overhead and/or syntactic noise in Rust/C++ (or alternatively, lack of memory safety); and (2), it becomes difficult to write code that works equally well for multiple and exclusive ownership (module APIs often become burdened with implicit or explicit ownership assumptions).


Gotcha. I'm not sure I agree, but I understand :)


Well, let me also add that I completely understand that there are use cases for Rust, where a GCed language would be a poor fit. An obvious example is a web browser ( :) ), where the x% memory overhead that comes with a garbage collector is just a price that you may not be able to afford to pay.

In other words, don't read this as "Rust sucks" (I actually rather admire Rust's design), read it as: for my purposes, the practical use cases of Rust are generally too niche to justify the software engineering tradeoffs.


Yeah, I hear you. I think this is fair. And at least some of it comes down to preference, that is, I don't think that the syntactic noise is very much, but others can certainly disagree. The others would mostly be a "nuh uh" since I don't have numbers anyway :)

At the end of the day, Rust can never be great for every single last programmer, and this is entirely okay.


I think that is his point, he thinks Rust and C++ cannot do this. But is the default in C++ and well done in Rust.


No, my point is not that it cannot be done (both Rust and C++ are Turing-complete, so "cannot be done" does not make sense for anything that's a computable property), but that it comes with a cost. See my other response for the details.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: