You hear fairly similar statements about linked lists from the C++ crowd too, where they're trivial to implement, so it's unlikely it's just defensive excuses.
Re:Why Rust closures are somewhat hard
by whyever on Tuesday September 11, 2018 @09:31AM
(#17959533)
They are are arguably about as trivial to implement in Rust. It becomes tricky when you add constraints: usually you want to avoid unsafe code, but even then you can just implement them on top of a vector and bypass any lifetime/aliasing issues.
Re:Why Rust closures are somewhat hard
by jcelerier on Tuesday September 11, 2018 @05:59AM
(#17958363)
> linked-lists are unnecessary, performance killers, and generally evil.
that's true on any CPU with more than 16kb of cache. linked lists were a good idea at the time of 486, not so much at the time of modern CPUs with 8+ megabytes of L3.
See https://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vecto...
That's all true, if you squint really hard, gloss over the equivalencies, discount the additional complexity, and ignore the basic simplifying elegance of linked-lists (particularly the so-called intrusive data structure implementations). But it's dramatically overstated because of a certain defensiveness.
What is absolutely true is that cyclical referencing is the bane of static analysis, and anathema to a language that leans so heavily on its typing system for modeling language semantics. What you think that implies depends on your faith in how far type-based, lifetime-based static analysis can go toward addressing larger issues in the software ecosystem.