How would that work? Rust "crates" are just a compilation unit that gets linked into the resulting binary.

By using the type system. You define your type constraints at the module interface point and when you try to link the third-party module into that interface the compiler ensures that the constraints are satisfied. Same thing the compiler is already doing in simpler cases. If you specify that a third-party library function must return an integer, the compiler will ensure that function won't unexpectedly return a string. Just like that, except the type system is expanded to enable describing more complex behaviours.

This is a nice exercise for compiler researchers.

I suppose it can be done on various levels, with various performance trade-offs.

That could be possible for browser apps which already have a sandbox. Doubtful for general purpose languages. For example I have a library and utility to change user password, or writing sudo alternative sudors etc. How would you even begin to sandbox that are core os utilities or need access to core os themselves.

more specifically, one can introduce policies into the runtime, or given rust hoist at least some of them into compiletime that would do things like (a) enforce syscall filtering based on crate or even function (b) support private memory regions for crates or finer grained entities that are only unlocked upon traversing a declared call-gate (c) the converse, where crates can only access memory they themselves have allocated except a whitelist of parameters (d) use even heavier calling conventions that rpc to entirely separate processes

An extremely verbose effects system can resolve these dependency permissions at compile time.

However, balancing ergonomics is a the big challenge.

I personally would prefer less ergonomics for more security, but that’s likely not a broadly shared opinion.

i dont know if it needs to be extremely verbose:

  fn prints_output(value: &str) @ mut std::io::Output {
    println!("side effects! value: {}", value);
  }
  
  effect CurrentTime {
    pub date_time: DateTime<Utc>
  }
  
  fn takes_context() @ CurrentTime dt -> String {
    dt.date_time.format("%H:%M").to_string()
  }
  
  // combine effects for shorter declarations
  // `?mut` is only mutable if the function declares it as `mut`
  effect TimeAndOutput = CurrentTime + ?mut std::io::Output;
  
  fn implicit_pass() @ mut TimeAndOutput {
    prints_output(takes_context());
  }
  
  fn creates_new_context() @ mut std::io::Output {
    // you only need to create the context thats not passed automatically
    implicit_pass(@CurrentTime { date_time: DateTime<Utc>::now() });
  }

effects can also have private fields and methods realized as a function pointer. that means `Output::print` can do different things in a simple cli app and a server framework with advanced logging. the calling function never knows the details.

syntax not final obviously and idk if it should be called "effect" or "context" so im using both. every function has to declare them but theres no big ergonomics hit when you have union effects and ide autocomplete. might not be easy to implement this in practice but the concept is simple, its basically some extra objects that get automatically passed through kinda like react context.

a function that takes no context and no &mut parameters is pure, if it takes only "shared" context its view (no side effects but depends on shared state). this can be used to let the compiler optimize better or guarantee security, like proc macros have to be pure or build.rs can only log to a provided output. of course you need to forbid unsafe code in the untrusted module to make it safe.