I mean yah. That’s what it takes. But like when I try to write code around Arc<_> the performance just tanks in highly concurrent work. Maybe it’s an OOP rust skill issue on my end. Lol.

Avoiding this leads, for me at least, to happiness and fearless, performant, concurrent work.

I’m not a huge fan of go-lang but I think they got it right with the don’t communicate by sharing memory thing.

[–] PlexSheep@infosec.pub 1 points 2 days ago (2 children)

You mean mutex? Arc allows synchronous read only access by multiple threads, so it's not a performance bottleneck. Locking a mutex would be one.

[–] tatterdemalion@programming.dev 5 points 22 hours ago (1 children)

Arc is not free, and the extra atomic operations + heap allocations can become a bottleneck.

[–] PlexSheep@infosec.pub 1 points 11 hours ago (1 children)

Oh, I did not know that. Well, it makes sense that it has a heap allocation, as it becomes more or less global. Though not sure why the atomic operations are needed when the value inside is immutable.

[–] Miaou@jlai.lu 1 points 6 hours ago

How can you otherwise keep track of an object's lifetime if copies are made concurrently?

[–] mholiv@lemmy.world 3 points 1 day ago* (last edited 1 day ago)

I mean it could be Mutex, or Rwlock or anything atomic. It’s just when I have to put stuff into an Arc<> to pass around I know trouble is coming.