3 ms·

IDE tooling / intellisense is improving but still weak compared to, say, C# IME - although I should maybe give IntelliJ another shot. It's still got a lot of l

IDE tooling / intellisense is improving but still weak compared to, say, C# IME - although I should maybe give IntelliJ another shot. It's still got a lot of low level building blocks in place but there are still gaps and mid-tier / high level frameworks are still missing for many problem domains. It's 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...) It's got a nice hefty stdlib, which is usually a boon, but can be annoying to port for weird platforms. There's almost always a working C++ environment available, but Rust takes more work. A concrete example: https://github.com/MaulingMonkey/rust-opendingux-test https://github.com/MaulingMonkey/rust-opendingux-test . And yes, that "Rust" repository does have 2 lines of C code in it ;). EDIT: Also, no standard/stable Rust ABI. And extremely limited dynamic runtime reflection via "dyn Any" (although pretty decent hygenic macros / proc macros and related crates makes the compile time stuff sufficient for most of my day to day needs). Still, C# DLL reflection is super nice at times, whereas Rust is "forced" to ship source code for libraries unless they want to jump through a bunch of hoops to limit the API surface to the C ABI... EDIT: Also, a lot of rust libraries are quick to adopt new features of the latest stable compiler. Tools like rustup make it trivial to stay on the latest stable compiler, but can make things awkward if you insist on apt-provided rustc, or if you need to customize the compiler or stdlib for your particularly oddball target platform (read: consoles, but not opendingux like I linked above) - this can be a pain point.

orthoxerox 6y ago
> 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)

orthoxerox 6y ago

> 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)