You seem to be mixing "designing" a linked list and just implementing a known design.

> which people generally shouldn't ever need

Agree!

However, we can still use the implementation of a "reasonable" linked list a good yard stick to measure things across languages since it usually involves a good coverage of basic language features (like collection, traversal, life time management etc... etc...).

Also, looking at the rust implementation of the linkedList you linked, we do have the magic unsafe keyword somewhere in there... which negate a lot of your argument have probable safety.

> Less perceived complexity.

This a seems very strange thing to say. Isn't reducing perceived complexity the name of the game in language design ? Reducing the complexity the dev have to carry in their mind by moving some of the decision to the toolchain is in my option a very valid approach.

> In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it.

> For extreme use cases, the behavior and overhead of the garbage collector does became relevant.

First, designing for non extreme case is a valid approach in language design. Make the common case dead easy, and for complicated/rare case, provide API and customization points. In .Net/Java it is possible (also not always easy) to beat the GC into submission.

Second, i think the comment about GC not being adequate for large scale web app is very 1990.New garbage collectors are able to manage those use case easily. A lot of the largest backend are in java.

> If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust.

Why would you factor the code of the garbage collector in the equation...

> However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C#

We are not talking about idiomatic vs non idiomatic. We are talking about simple and not simple. Writing GC friendly code in Java (even better in C# in my opinions with Structs) is still relatively simple and clean.

> You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist.

The unsafe keyword in the implementation pretty much negate all of this...

> Yes, you may have provided your team with a linked list, but it will either (1) Perform less efficiently, due to needing the GC to check whether to free things (2) Require more expertise to use safely, due to C++ being incapable of expressing constraints

1) is a very strong statement, GC code can perform better than manual memory management, and does in a lot very real case.

GC vs non GC is not about performance or efficiency, it's about control. Do you want to do it, or do you want the system to do it. The best parallel is register allocation : can you do a better job than the compiler in some case ? maybe. But in average (especially when you had things like x-function register allocation) in most case the compiler beats every dev except the top 5%.

> In the context of Java and C#, Rust hasn't "increased complexity", it makes it explicit rather than paying runtime cost to try and hide it. In the context of C++, Rust hasn't "increased complexity" either, it makes it mandatory to deal with things that C++ lets slide.

Making it explicit is increasing the complexity...

> it makes it mandatory to deal with things that C++ lets slide.

And thus making it "harder" to produce the same code...

> But it's not like Rust added that complexity - it was always there. C++, C#, and Java just let you ignore at the risk of adversely affecting software stability or performance, respectively.

I don't have a nice way to say it, just gonna say it : This is what fanboyism sounds like. C++/Rust and java are different point in the language design point. Now they are not perfect, as in it might be posssible that for each their respective domain, we can with the benefit of hindsight design something that works better. But to think that rust magically found a point in that design space which doesn't also add another sets of compromise is not realistic.