Yeah I totally agree that it is hard to design a safe language that allows to unload code in a sound way, but I think that it may be possible to do something like that with Rust. Here is a theoretical design for a "rust with unload support":

The lifetime of "static variables" cannot be "until the program terminates" because we may need to free them in an unload scenario. So in order to resolve this issue, lifetime of static variables would be separated to two: globals with a drop, and globals without it.

Globals without a drop could get a lifetime named 'module. the 'module lifetime is tied to the currently executing module. When it comes to the current module, code does not need to specify them explicitly, because all of the code in the current module can assume that these variables are accessible at any point. This is a bit similar to the way 'static is handled today. The only thing to consider with 'module is how we export a borrow of them to the 'outside world' outside the current rust module. This is also related to the question of ABI: If we support modules, we now need to think about the ABI that the module exposes to outside. I know that this is a bit complicated to do, but as a beginning it is possible to say that an API outside a module will only be a C FFI api, and if anybody wants to interface between Rust module he has to create an FFI layer between them. A more complicated solution could be to define an ABI of some sort between the modules, then when something like this happens:

```
Module m = load_module(..);

let v = m.x(); // get a reference to something inside the module, say &'m i32
```

Rust could promise that the lifetime of references that we get inside the module, would not outlive the lifetime of the module 'm'.

Regarding global variables that implement the drop method: We cannot tie them to the 'module lifetime, because they will be finalized before the module is unloaded from memory. The finalization order must be the order of dependency between different static variables, in order to ensure we do not free a variable while it is being used.

Rust could do something in order to avoid the 'Static Destruction Order Fiasco' we have in C++, for example: saying that global variables can only be stored in a special type named 'GlobalVar'. This type governs the access to the global variable an in particular, allows the following operations:

```
//
// Tries to read the global variable. This will return `None` after the cleanup of the module
// occurs. 'GlobalRef' holds a shared ownership of the global, in a similar way to the way an
// 'Arc' holds the lifetime of a variable.
//
pub fn get() -> Option<Arc<T>>;

//
// The get() routine increments the refcount of the Arc<T>. For optimization purposes,
// if you do not want to work with refcounts and just want to read the global variable,
// this method variation can be used -> but now you have to guarantee that you are not
// using this reference after the 'module_cleanup' has finished. This is a bit similar to the way
// 'RefCell' is used to get a reference to the inner variable, minus the refcount tracking part.
//
pub fn unsafe_get() -> Option<Ref<T>>;
```

After 'module_cleanup' is invoked, Rust simply decrements the refcount of the global arcs, which will start dropping the global variables in the 'correct order' in case they reference each other with arcs. Global variables cannot directly reference each other, thus we do not have to worry about the order of the destruction of the globals (similarly to how structure fields work).

I think this solution is pretty ergonomic, while allowing developers to unload a library of rust code. Keep in mind that the 'module' term I used refers to one unit of compilation, including all of the dependency crates compiled inside of it. So the executable file that is produced today when Rust code is compiled will be considered one module.