The ArrayList is just a growable array and is presumably using an exponential growth strategy so it's equivalent to what several of the others are doing. You could indeed tell Java how big the ArrayList will grow in advance, but you could for example likewise do that with the Rust Vec by asking for Vec::with_capacity(num_tasks) instead of Vec::new().
Since this is amortized exponential growth it's likely making negligible difference, although it is good style to tell data structures what you know about their size early.
The Go approach doesn't appear to pay this penalty, it's just incrementing a (presumably atomic?) counter, although I have no idea where these tasks actually "live" until they decrement the counter again - but most of the others are likewise using a growable array.
It looks like most of the languages are doing the same thing w.r.t using a 'List'-style implementation that re-sizes/copies it's internal buffer when it runs out of space.
One thing I wonder though is whether the managed languages pay a bigger penalty on the memory usage than the unmanaged languages due to this.
In the unmanaged languages, those intermediate buffers should be freed immediately during the re-size operation.
But in the managed languages, they might stick around until the next GC. So the peak memory would be higher.
In this example the runtime overhead is going to represent more of the memory usage anyway but it quickly isn't negligible. E.g. a list of size 1M is going to be ~8MB (64 bit addresses). So even if the array is re-sized from 1->2->4->8->...->~500K, the end result is not going to be worse than 2X the size.
Since this is amortized exponential growth it's likely making negligible difference, although it is good style to tell data structures what you know about their size early.
The Go approach doesn't appear to pay this penalty, it's just incrementing a (presumably atomic?) counter, although I have no idea where these tasks actually "live" until they decrement the counter again - but most of the others are likewise using a growable array.