4 ms·
"Sure, but it would have been a legitimate choice to let + do that" Yes, it is a legitimate choice indeed. Many fine languages have made that choice. But it i
by jerf 5y ago
"Sure, but it would have been a legitimate choice to let + do that"
Yes, it is a legitimate choice indeed. Many fine languages have made that choice.
But it is also a legitimate choice not to. We need at least some languages that don't do that. We really don't have very many that are this careful about allocation. Most of programming language history since C and C++ has been trying to "fix" this problem, and make allocations easier. Rust has chosen to be one of the languages that stays at the highest level of care about allocations. As a result, it will not just casually allocate memory for strings.
That's what this is; a design choice. If you don't like it, don't use Rust. I generally don't use Rust, because my tasks don't call for this level of control. But if I ever do have a task with that level of control, I know where to go get the tools to solve that problem, and I'm glad that someone made that choice. I'd be in real trouble if nobody chose that.
(Another example of a common pattern in programming language history can be seen happening here, too. C and C++ were this careful about allocations for the most part, but they made it really hard to use at all, and borderline impossible to use safely. Then, people incorrectly attributed that difficulty to being careful about allocations, and subsequent programming language design went in the direction of getting away from that level of care. But what we see in Rust is that if you are that careful, and add in a better toolset to deal with it, you can blunt the disadvantages while reaping the advantages. The disadvantages don't entirely go away, but if you reduce the "costs" in the costs/benefits analysis, the benefits become more attainable for engineers, especially when tooling can be developed to also increase the benefits. Haskell doesn't do this with allocation but it has a similar story for the things like how hard strong typing is. IMHO the mid-1990s to 200xs in programming languages was a story of running away from hard problems, but the big story in the 2010s has been the running towards hard problems, and I'm liking the results.)
- vintermann 5y ago> We really don't have very many that are this careful about allocation. You're missing the point. I don't think this is being careful about allocation. There is potential allocation either way - when your string (or vec) grows, allocation under the hood may be necessary too. Do you see my point? Surely doing the allocation inside "a" isn't better than just allocating a new "c" for explicitness' sake. It may be better for performance's sake, but that's not justification enough for making (+) an impure function as I see it. We could always just write it out as .append(b) or whatever if that's what we wanted.
- Arnavion 5y agoYou're welcome to dislike it because it's "impure". Actually, depending on how rigidly you define purity, either both implementations are pure (both return the same output for the same input) or both implementations are impure (both modify global state via the implicit global allocator). But you're mistaken in thinking it's something obvious such that others should agree with you. As I said previously, the reality is that you cannot write a program that lets you differentiate whether String + &str reused the same String or allocated a new one. So your hangup is entirely over the documentation revealing the extra information that it has the efficient implementation, not the inefficient one.
- Dylan16807 5y agoThe entire point of passing in a String, according to the article, is to "force you to be aware that you will have to allocate". But you're saying that an extra hidden allocation doesn't matter and you shouldn't have a "hangup" about it? Trying to follow the same rules as the article seems reasonable to me, not a "hangup".
- Arnavion 5y ago>But you're saying that an extra hidden allocation doesn't matter and you shouldn't have a "hangup" about it? No. I recommend reading the subthread the comment was made in more carefully.
- Dylan16807 5y agoThe comment you replied to was talking both about the negatives of hidden allocations and about purity, so I thought you were addressing both. If you are only talking about purity then okay I have no comment.
- Arnavion 5y ago>The comment you replied to was talking both about the negatives of hidden allocations and about purity That is incorrect. The comment was requesting that `Add::add(String, &str) -> String` should be impled by creating a new String instead of mutating an existing one. My comment pointed out why this request was meaningless.