> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds.
I remain to be convinced that this is possible.
Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they could be with GC (like iterators).
If you make a language GC by default with opt-in ownership, what does your standard library look like? It either isn't usable in ownership code, or it's crippled for GC code.
I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader.
I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.
The obvious solution is that the standard library would provide both options wherever appropriate, just like Rust has `borrow` and `borrow_mut`, `raw_entry` and `raw_entry_mut`, etc. You might be able to save some of this pain with some polymorphism, as some people suggest[0] for `&` and `&mut`, too.
It might also be a good idea to look at the standard library of Idris 2[1] — it has linear types and garbage collection, so it has many of the same issues you describe, and it also seems to solve them with duplication where necessary[2], at least sometimes.
Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.
I remain to be convinced that this is possible.
Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they could be with GC (like iterators).
If you make a language GC by default with opt-in ownership, what does your standard library look like? It either isn't usable in ownership code, or it's crippled for GC code.