Visual C++ also has an unmanaged heap, though. If you restrict your program to use that, you would think you avoided the garbage collector, but reading https://msdn.microsoft.com/en-us/library/yk97tc08.aspx, that isn't the case ("The system uses the CLR garbage collector mechanism to determine if the object is no longer being used and can be deleted")
So, Microsoft hasn't managed to avoid using the garbage collector.
You still could write a language that didn't rely on it, though. For example, you could prevent anything from being garbage collected by maintaining a global hash map containing every explicitly allocated object (possibly with optimizations for local objects that the compiler can prove do not escape)
Alternatively, you could have your runtime do everything in one huge byte array. I doubt that would be efficient, though.
The reason for that is likely because many libraries would simply stop working. Anyone who has written lock-free C++ and lock-free managed understands the fundamental reasons why explicit memory management could never be added. Even if you exclude threading, things remain broken: the entire BCL would need to be rewritten and most likely suffer drastic API changes. The problem of allocation lifetime impacts API design to a very large degree. As soon as you call code that assumes implicit allocation management (BCL), you lose all guaranteed knowledge about lifetime.
What would be nice is to be able to tell the GC something along the lines of "this weak reference is pointing to something that is most likely garbage." It could then tune its heuristics for that object and collection in general.
> huge byte array
Huge struct arrays are commonplace in perf critical code (e.g. particle systems). They work quite well because they are O(1) during marking and should quickly promote to G2.
Visual C++ also has an unmanaged heap, though. If you restrict your program to use that, you would think you avoided the garbage collector, but reading https://msdn.microsoft.com/en-us/library/yk97tc08.aspx, that isn't the case ("The system uses the CLR garbage collector mechanism to determine if the object is no longer being used and can be deleted")
So, Microsoft hasn't managed to avoid using the garbage collector.
You still could write a language that didn't rely on it, though. For example, you could prevent anything from being garbage collected by maintaining a global hash map containing every explicitly allocated object (possibly with optimizations for local objects that the compiler can prove do not escape)
Alternatively, you could have your runtime do everything in one huge byte array. I doubt that would be efficient, though.
[and in case you don't know: C# has real destructors (https://msdn.microsoft.com/en-us/library/66x5fx1b.aspx). Unfortunately, they can only be used with classes.]