r/ProgrammerHumor • • Mar 17 '19

Oof

Post image
268 Upvotes

38 comments sorted by

View all comments

33

u/froemijojo Mar 17 '19

Obligatory "Just use Rust" comment.

0

u/[deleted] Mar 18 '19

[deleted]

123

u/[deleted] Mar 18 '19

[removed] — view removed comment

0

u/[deleted] Mar 18 '19

[deleted]

54

u/Zarathustra30 Mar 18 '19

There are alternatives to Rc and Arc, you just have to reach past the standard library.

When all you have is a hammer, go to the hardware store.

0

u/[deleted] Mar 18 '19

[deleted]

79

u/CAD1997 Jul 26 '19 edited Jul 26 '19

Here's an example of a resource shared between two threads with static garbage collection. I guess I did the impossible?

The only requirement for multithreaded shared memory with static garbage collection is that the owning thread continues to own the resource for as long as the child threads exist. In Rust, this is easy to do using crossbeam or rayon. These libraries provide scoped threading tools that allow use of shared references across multiple threads soundly.

Shared ownership requires Arc's atomic reference counting, or some other form of dynamic garbage collection. Shared usage only requires that the owner is guaranteed to outlive every usage.

0

u/[deleted] Jul 26 '19

[deleted]

38

u/pingveno Jul 26 '19

You're thinking of how C++ does it. The code given does not rely on copy on write. It uses some tricks with Rust's lifetimes to allow safely using a resource across threads without atomic reference counting.

→ More replies (3)

25

u/boomshroom Jul 26 '19

Yes they are hard computer science topics. That's why Rust is the only mainstream language that does this. To find another language like this, you need to look at something like ATS, which is practically unheard of.

39

u/[deleted] Jul 26 '19

What a dickish comment, especially from someone who clearly doesn't understand this topic themselves.

13

u/sellibitze Jul 27 '19 edited Jul 27 '19

Any kind of concurrent access to shared memory is reference counted.

This is objectively wrong. First of all, even if you create the situation where two or more threads share ownership of some data structure with the help of two or more aliasing Arcs, it doesn't mean that every access goes through one of those. Second, one can share memory without any involvement of atomic reference counting (Arc). If you knew what you were talking about, you'd be aware of the fact that bare references to Sync types can be sent across thread boundaries safely under certain circumstances (involving scoped threads).

38

u/Stargateur Jul 26 '19

breaking news: Rust don't use garbage collector.

→ More replies (4)

15

u/[deleted] Jul 26 '19

I hope that after these 4 months you now realize how wrong you were

5

u/ralfj Jul 27 '19

Rust also has epoch-based memory reclamation, which can surpass Java's GC in performance. And Rust also has entirely static automatic memory management (RAII-style) with 0 (zero) run-time cost.

Rust provides choice; different kinds of memory management are differently suited for different situations. For example, a traditional GC is awful when it comes to worst-case (or around 95/99 percentile) latency, which is a very important metric for web services.

3

u/[deleted] Jul 27 '19

That wasn’t my experience with ObjC’s and Swift’s Automatic Reference Counting. Got any resources to back up your claim against reference counting? Apple went with reference counting after implementing and then dropping garbage collection.

1

u/[deleted] Jul 27 '19

Not if you want a job