runtime check. Which in turn results in a runtime performance.
If you’re calling drop on a mutable string that’s been extended repeatedly, you’re recursively dropping all kinds of mess all over the heap. Checking for zero beforehand has an insignificant impact. Those cache misses you had because rust pays less attention to “where” than it does to “whether”, they cost you a lot more than the reference count check. In the real world, in practice, under profiling of real code, the cache misses and the branch misses are more expensive than the reference counting.
You sound a little bit like a C programmer who claims his code is fast because his arrays don’t do bounds checking. That’s not why C is fast. Similarly rust isn’t fast because it never does runtime reference counting. It does sometimes, but that code isn’t pathologically slow.
Also, rust isn’t just fast because of the borrow checker, primarily it’s memory safe because of the borrow checker.
If it’s any consolation, afaik, most of the roc platforms are written in rust. Also afaik only application specific code is written in roc. There are no memory management primitives in roc code unless a platform author exposes them in their api/interface, and I don’t think anyone is working on implementing C on top of roc.
I don’t know what you read on my reply. But your reply makes no sense.
Let me rephrase it if you prefer:
Claiming that Rusty’s borrow checker is reference counting is hugely misleading. Since the borrow checker was made specifically to prevent the runtime cost of garbage collection and reference counting while still being safe.
To anyone unaware, it may read as “rust uses reference counting to avoid reference counting, but they just call it borrow checking”. Which is objectively false, since rust’s solution doesn’t require counting references at runtime.
I don’t know what mutable string or any of the other rant has to do with reference counting. Looks like you’re just looking to catch a “rust evangelist” in some kind of trap. Without even reading what I said.
If you’re calling drop on a mutable string that’s been extended repeatedly, you’re recursively dropping all kinds of mess all over the heap. Checking for zero beforehand has an insignificant impact. Those cache misses you had because rust pays less attention to “where” than it does to “whether”, they cost you a lot more than the reference count check. In the real world, in practice, under profiling of real code, the cache misses and the branch misses are more expensive than the reference counting.
You sound a little bit like a C programmer who claims his code is fast because his arrays don’t do bounds checking. That’s not why C is fast. Similarly rust isn’t fast because it never does runtime reference counting. It does sometimes, but that code isn’t pathologically slow.
Also, rust isn’t just fast because of the borrow checker, primarily it’s memory safe because of the borrow checker.
If it’s any consolation, afaik, most of the roc platforms are written in rust. Also afaik only application specific code is written in roc. There are no memory management primitives in roc code unless a platform author exposes them in their api/interface, and I don’t think anyone is working on implementing C on top of roc.
I don’t know what you read on my reply. But your reply makes no sense.
Let me rephrase it if you prefer:
Claiming that Rusty’s borrow checker is reference counting is hugely misleading. Since the borrow checker was made specifically to prevent the runtime cost of garbage collection and reference counting while still being safe.
To anyone unaware, it may read as “rust uses reference counting to avoid reference counting, but they just call it borrow checking”. Which is objectively false, since rust’s solution doesn’t require counting references at runtime.
I don’t know what mutable string or any of the other rant has to do with reference counting. Looks like you’re just looking to catch a “rust evangelist” in some kind of trap. Without even reading what I said.