Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

One of the interesting things about MMM and borrow checking is that it enables you to implement GC and RC. Rust has RC built in of course, but the general consensus seems to be that it's "not idiomatic". There's also crates for GC. Would a Rust project that relied heavily on GC be able to sustain the sort of velocity that a project in a native-GC language had? Would it even be close?

I love Rust's developer experience, frankly. The macros and build system are the main reason I like the language. I hate the borrow checker most of the time, for exactly the reasons listed in the article. It's probably a terrible choice for a 7DRL project, unless it was some sort of Rust core with content that was primarily orchestrated from another language (possibly DSL).

View on HN

I’m not sure regarding the benefits of adding such a library-GC (that effectively does RC with cycle detection) to Rust. RC is just very slow and there is a very good reason that no performant managed runtime uses it. They are good in that they need no explicit support from the runtime, but that only makes them possible, not performant.

I would wager introducing a small rust hot loop via FFI into a managed language is a much saner route, using the respective languages to the best of their abilities.

Obligate ARC is slow. RC/ARC as used in Rust (ARC separately marked, only used when required for thread safety; RC in general only for objects that may need to be kept around by multiple parts of the program, with no fixed "owner"; with simple RAII used for everything else) is very fast, comparable to manual memory management.

It can remove a few increments/decrements (more like a single pair at inlining a function), but that’s not what makes it problematic.

If you do have a bigger object graph, not using it anymore will recursively go on and decrement the counters, removing potentially many objects from memory, totally killing the given thread’s cache/performance. All that is amortized with a tracing GC. On top, atomic counters are very expensive.

Of course you can probably get away with using (A)RC at few places at most with Rust, but if you decide to track object lifetimes with RC for loads of objects, it will have a price (which may or may not be worthy. In my opinion, it is better to stick to Rust for low-level programs)

Makes sense from a performance standpoint. But what about development velocity? If the hypothesis is that wrestling with the borrow checker is a big drain on productivity, then bypassing it should restore that productivity.

> I love Rust's developer experience, frankly. The macros and build system are the main reason I like the language

On the contrary, I hate the macros, because the formater can't format inside tokio select or some of the other macros, and that means I have to do it manually, which is lame.

That's a pretty weak reason to hate macros, frankly. Seems more like a deficiency in the formatter than in the language feature.

As a side note, there's a poorly-documented behavior where rustfmt will format macros that are wrapped in {} if it's valid rust code. So you can even point the blame on tokio for not using formatter-friendly macros.

I agree, that is a weak reason to dislike macros.

I dislike them primarily because of the additional complexity they add that isn't always justified. All of the more complex macros I wrote I regret, especially the one I did at my last job since now others had to maintain it.

Some macro use can be justified, eg serde. But I try to avoid using proc macros where I can (and certainly never try write one anymore)

Reply on news.ycombinator.com