Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.

You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is.

Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model.

What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust.

[0] https://doc.rust-lang.org/1.1.0/arena/index.html

>The unpredictable aspect is the stop the world pause caused by garbage collection.

As well as malloc pauses on deallocation. The only way of using your memory in realtime apps is preallocation, which often can be done in languages with GC too, it would be just very inconvenient.

At the moment custom allocation support in rust is a joke if you compare it with Ada or C++, and Box is not better than GC in this regard.

>Unstable

Besides it's very inconvenient to use. Does Box/Rc/Arc support this arena allocator, as C++'s smart_pointers do?

Threads are an implementation technique, not a user requirement (at least they shouldn't be).