Re:The borrowchecker is what I like the least about Rust
by vlovich123 on Saturday July 19, 2025 @04:30PM
(#44619091)
Why compile to Rust for this? Many people that build transpilation languages target C directly.
Re:The borrowchecker is what I like the least about Rust
by lblume on Saturday July 19, 2025 @05:03PM
(#44619378)
Think of Rust as a kind of kernel guaranteeing correctness of your program, the rules of which your transpiler should not have to reimplement. This may be compared to how proof assistants are able to implement all sorts of complicated simplification and resolution techniques while not endangering correctness of the generated proofs at all due to them having a small kernel that implements all of verification, and as long as that kernel is satisfied with your chain of reasoning, the processes behind its generation can be entirely disregarded.
Re:The borrowchecker is what I like the least about Rust
by nine_k on Saturday July 19, 2025 @04:35PM
(#44619146)
A C compiler won't complain if your generated code does certain horrible things.
Re:The borrowchecker is what I like the least about Rust
by nine_k on Saturday July 19, 2025 @04:35PM
(#44619140)
Why, macros that put Arc<Box<T>> everywhere might just be it.
Re:The borrowchecker is what I like the least about Rust
by lblume on Saturday July 19, 2025 @05:06PM
(#44619405)
Arc<Box<T>> is redundant, for the contents of the Arc are already stored on the heap. You may be thinking of Arc<Mutex<T>> for multithreaded access or Rc<RefCell<T>> for singlethreaded access. Both enable the same "feature" of moving the compile-time borrow checking to runtime (Mutex/RefCell) and using reference-counting instead of direct ownership (Arc/Rc).
I haven't written a ton of Rust so maybe my assumptions of what's possible are wrong, but it is an idea I've come back to a few times.