new | ask | show | jobs
t43562 3 days ago  [ - ]

I'm experiencing that shock now. Can't create a global instance of my self-made heap datastructure. I'm longing for C memory management at the moment - it seems a tiny price to pay.

Now I learn that linked lists aren't possible and one has to use some, frankly, bullshit scheme to pretend to have them. IMO the documentation isn't really preparing people for the new reality of what can be done and how to do things.

simonask 2 days ago  [ - ]

Linked lists aren’t just possible in Rust, they are in the standard library.

They are just an example of the borrow checker’s limitations, which mean that you can only form a DAG of mutable references. But that’s why we have `unsafe`.

binarymax 3 days ago  [ - ]

The way I think about rust is this: you can experience the pain up front while you’re getting your program to compile, or you can experience pain later during runtime in random unpredictable ways. Rust is the former. It takes time to learn how to reduce the up front pain, but I’m so much more confident in the end result.

I say this having years of coding background in languages like C, C#, Java, JavaScript, Python, etc.

t43562 2 days ago  [ - ]

It's fair enough but if one isn't writing multi-threaded code or code with some complicated ownership scheme then that upfront investment may never really deliver a return.

binarymax 2 days ago  [ - ]

Not true. Whole classes of bugs are just eliminated - most importantly NPEs. I’ve seen tiny scripts in node that crash due to lack of an exception handler, and I’ve witnessed countless runtime errors in Java in the simplest of web services.

t43562 2 days ago  [ - ]

I've written utility programs that never bother to deallocate memory because the program needs all of it until the point where it exits anyhow.

estebank 2 days ago  [ - ]

You can do the same in Rust with Box::leak, which takes an owned pointer and gives you back a 'static borrow. The only caveat is that unless you reconstitute the type its Drop impl won't be called, but that's likely exactly what you wanted.

acdha 2 days ago  [ - ]

That’s certainly possible but I think it’s increasingly untrue for all but the smallest programs. The problem is that it’s hard to appreciate how many times your program didn’t crash but would have if you’d used a different language. You don’t need to be very complex before you have the risk of something crashing due to an edge case around values which are almost never null, even in languages like Python.

t43562 2 days ago  [ - ]

My productivity level in C is medium. In rust I'm competely blocked because I want to create a global variable and absolutely none of the described ways in the docs or stackoverflow work for my example. Should I give up on this "bad idea".....well I cannot because I can't accept not understanding why this is not working when people say it can.

Compared to C the situation is outlandishly, even hellishly impossible to understand. If I can't understand this one thing then I feel there's no point in continuing so I must stay and battle it till I get it or give up completely. I don't think I've ever hit anything like this in any other language I've ever learned.

AnyTimeTraveler a day ago  [ - ]

Have you thought about just not making the variable global and instead adding it as a parameter to the functions that actually need it?

You can also create a struct, put your "global" variable inside it and then put all the functions that need the variable into an Impl block of that struct. If you then add the parameter `&self` to these functions, you can access the "global"variable any time via `self.global_variable`.

If that is not enough, then you can always make an actual global variable by first wrapping it in a Mutex, to prevent simultaneous access and then wrapping that in an Arc for Atomic Reference Counting. That allows you to pass "copies" of that variable around anywhere, satisfying the borrow-checker (since the variable is now reference-counted in a thread-safe way).

If you need a lot of parallel reading, replacing the Mutex with an RwLock is a good idea, since it allows locking from multiple threads, if you want to read it in most cases.

rstuart4133 18 hours ago  [ - ]

You've said "I want to create a global variable and absolutely none of the described ways in the docs or stackoverflow work for my example" a few times now, and I still have no idea what you are stuck on. Global variables are much the same in C and Rust, as ownership problems largely disappear for global variables.

Maybe if you provided the example, someone might provide an insight. I hate to suggest this - but have you asked an AI? They've seen a lot of code. If you give an AI enough context it will likely cough up examples of how others have solved it.

t43562 7 hours ago  [ - ]

Thank you for offering to look. I hesitate to supply the example because I have tried so many things and get so many different errors depending on what approach I try to take.

I don't want to waste your time. What I'm doing now is just trying to make global variables with builtin data types like String. This takes away some of the options for error. My idea is to get this working before I try to do it with my own data structure:

So with a simpler case where I'm making a global string instead

  // ....
   static mut HEAP_INSTANCE : OnceLock<String> = OnceLock::new();

  #[rocket::main]
   async fn main() -> Result<(), rocket::Error> {

      HEAP_INSTANCE.set("blah".to_string());

      ^^^^^^^^^^^^^ use of mutable static

      let _rocket = rocket::build()
          .mount("/", routes![min,create_heap])
          .launch()
          .await?;

      Ok(())
   }
As you can see it's an error to use a static mut. I realise that this thing isn't safe in a multi-threaded program but I had hoped that I might ignore that in my single-threaded program or add some kind of locking container that would make it acceptable to the compiler.

If I try to use my heap data structure then I start having a multitude of issues, the most common being that I create something which is owned by a scope that disappears too soon. IOW I need to initialise the global with a structure that has a 'static lifetime and I'm doing that in a context which definitely isn't static. i.e. I get "creates a temporary value which is freed while still in use" or something similar

While writing this reply I might have solved my issue:

  //static mut HEAP_INSTANCE : OnceLock<String> = OnceLock::new();
  static HEAP_INSTANCE : OnceLock<Box<Heap<String>>> = OnceLock::new();

  async fn main() -> Result<(), rocket::Error> {
    let heap = Box::new(Heap::new(100));
    let _ = HEAP_INSTANCE.set(heap);
    // ....
  }
I don't fully understand why I don't need the mut and I don't know if I really need a Box or not but at least this compiles.

Thank you for helping me to duck debug! :-D

estebank 2 days ago  [ - ]

The counterpoint I'd have for this argument is that code that isn't multithreaded or with complicated ownership scheme ends up being very simple looking Rust, so the difficulty of the language doesn't come into play.

15155 2 days ago  [ - ]

https://docs.rs/once_cell/latest/once_cell/#lazy-initialized... ?

bfLives 2 days ago  [ - ]

It’s even in the standard library now: https://doc.rust-lang.org/std/cell/struct.OnceCell.html

afdbcreid 2 days ago  [ - ]

Have you tried to write a linked list as an exercise? I know it's a common beginner exercise in C and C++, but in Rust I really don't recommend implementing data structures as a beginner. While some are possible to implement safely, most require unsafe to implement at least efficiently and aren't very beginner friendly.

estebank 2 days ago  [ - ]

Have you read https://rust-unofficial.github.io/too-many-lists/?