4 ms·

> Its strictness, while generally useful in the long run, can be more of a drag than a boon for quick and dirty projects (although the more I use it, the faster

> Its strictness, while generally useful in the long run, can be more of a drag than a boon for quick and dirty projects (although the more I use it, the faster I'm getting with dealing with said strictness...) I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". Maybe I don't have enough experience writing Rust, but I don't enjoy switching from thinking about domain logic to thinking about memory management every time I want to run a unit test.

unrealhoang 6y ago
There’s `Box::leak` that you can use to turn your object into a static pointer.
perryizgr8 6y ago
> I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". That's exactly what C is. The truth is you need to be always thinking of memory. If you care so much about the domain problem, you should choose a different language. Python and javascript are both very good at letting you grapple with your problem, without worrying about the computer. Once you have solved it, and need a performant implementation, come back and write it in rust. And this time you need to be worrying about memory. C lets you ignore that and that's what rust was designed to prevent.
MaulingMonkey 6y ago
Rc<RefCell<...>> / Arc<Mutex<...>> and borrowing or locking for micro-scopes, only exactly when you need the inner values, will get you pretty far when you're looking to turn off your brain. Sometimes they're even the correct choice! It's not entirely frictionless, but it can get pretty smooth. Cell / Atomic* can be nice too.
umanwizard 6y ago
> I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". This couldn’t work because running destructors is sometimes required for actual correctness, not just reclaiming memory. (E.g., you might have a type that writes some records to a file and flushes the outstanding records in memory to disk when dropped)

unrealhoang 6y ago

There’s `Box::leak` that you can use to turn your object into a static pointer.

perryizgr8 6y ago

> I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". That's exactly what C is. The truth is you need to be always thinking of memory. If you care so much about the domain problem, you should choose a different language. Python and javascript are both very good at letting you grapple with your problem, without worrying about the computer. Once you have solved it, and need a performant implementation, come back and write it in rust. And this time you need to be worrying about memory. C lets you ignore that and that's what rust was designed to prevent.

MaulingMonkey 6y ago

Rc<RefCell<...>> / Arc<Mutex<...>> and borrowing or locking for micro-scopes, only exactly when you need the inner values, will get you pretty far when you're looking to turn off your brain. Sometimes they're even the correct choice! It's not entirely frictionless, but it can get pretty smooth. Cell / Atomic* can be nice too.

umanwizard 6y ago

> I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". This couldn’t work because running destructors is sometimes required for actual correctness, not just reclaiming memory. (E.g., you might have a type that writes some records to a file and flushes the outstanding records in memory to disk when dropped)