[YetAnotherNick]

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile.

Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc<Box<..>>.

[matesz]

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware.

However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies.

[1] https://github.com/makepad/makepad/

[flohofwoe]

IMHO Makepad also has an exceptionally readable Rust code style, which is a very rare thing (maybe that simple Rust style even contributes to the good build times, dunno) - but also: from the pov of a C programmer, 200 kloc in 10..15 seconds is still quite bad ;)

[timschmidt]

How quickly can you verify the memory safety of that C program in addition to compiling it though? When comparing like to like, C no longer looks so fast.

[gkbrk]

Rust code with unsafe still compiles slowly. And safe subsets of C still compile quickly.

[timschmidt]

That is exactly the opposite of my experience.

[YetAnotherNick]

I used actix web, could it be the reason for slow compile?

[matesz]

I am not completely sure, but I think pretty much all frameworks in Rust have complex dependencies and codebase not optimized for fast compile times. You could check out Axum [1], at the first glance seems similar to actix [2]. Both use tokio which is by itself pretty big I think.

Folks at makepad poured enormous effort in keeping dependency graph minimal.

[1] https://github.com/tokio-rs/axum/

[2] https://github.com/actix/actix-web/

[Fiahil]

> after the number of times I resorted to things like Arc<Box<..>>.

... What are you doing ? It's definitively unusual.

[dvt]

> ... What are you doing ? It's definitively unusual.

No it's not, it's extremely common. `Arc<Box<...>>` or `Arc<Mutex<Box<...>>>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely clear, knowing exactly what parts of every struct is shareable (Arc) & mutable (Mutex).

[1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

[Fiahil]

> No it's not, it's extremely common.

Arc-Mutex yes, Arc-Box no.

It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html

> The type Arc<T> provides shared ownership of a value of type T, allocated in the heap.

Moreover, you don't even need the box for a dyn : https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3...

[dvt]

> Arc-Mutex yes, Arc-Box no.

Yeah, looks like Arc-Box is kind of pointless, but isn't there some thread locality reason why people wrap `Box` in `Arc`? I remember reading something about it a while ago but maybe I'm misremembering.

[MaulingMonkey]

To play devil's advocate:

`Arc<T>` places the refcounts immediately before `T` in memory. If you are desperate to have `T` and `T`'s refcounts be on different cachelines to reduce false sharing in some contrived scenario, `Arc<Box<T>>` would technically accomplish this. I think a more realistic optimization would be to pad the start of `T` however.

`Box<Box<T>>` and `Arc<Box<T>>` are thin pointers (size ≈ size_of::<usize>()) even when `Box<T>` is a fat pointer (size ≈ 2*size_of::<usize>() because `T` is `str`, `[u8]`, `dyn SomeTrait`, etc.). While various "thin" crates are typically saner alternatives for FFI or memory density (prefixing lengths/vtables in the pointed-at data instead of incurring double-indirection and double-allocation), these double boxes are a quick and dirty way of accomplishing guaranteed thin pointers with only `std` / `alloc`.

I would not call either of these use cases "extremely common" however.

[YetAnotherNick]

I don't exactly remember the exact thing I used that's why I said "I resorted to things like.. ". Also, I used actix web, which could be the reason of slow compiling code.

[flohofwoe]

At that point a regular GC is probably faster (at least from my experience of doing memory management in C++ with ref-counted smart pointers, which has a 'death-by-a-thousand-cuts' performance profile, e.g. the refcounting overhead is smeared over the whole code base and doesn't show up as obvious hotspots in the profiler).

[PartiallyTyped]

Compiling clippy certainty doesn’t take that long and it’s a substantially larger project. What you describe is pretty weird to be honest.