> Library-defined containers, iteration and smart pointers. Containers, iteration and indirect-access operations (along with arithmetic) comprise the inner loops of most programs and so optimizing their performance is fairly paramount; if you make them all do slow dispatch through user code the language will never go fast. If user code is involved at all, then, it has to be inlined aggressively. The other option, which I wanted, was for these to be compiler builtins open-coded at the sites of use, rather than library-provided. No "user code" at all (not even stdlib). This is how they were originally in Rust: vec and str operations were all emitted by special-case code in the compiler. There's a huge argument here over costs to language complexity and expressivity and it's too much to relitigate here, but .. I lost this one and I still mostly disagree with the outcome.
Trust me, you do not want to put this stuff into the compiler. It's not just that it's cheating for perf, but it's confusing to users (no source code to read how these work) and frustrating that they can't write their own. Ultimately what this really means is that these things are indeed written in some language--the compiler's IR. JavaScript actually has a ton of this kind of things and every JS engine has gone through multiple generations of "what language do we write Array.sort in!?". In V8, these intrinsics are written in a DSL because doing them in asm, a special dialect of C++, or one of two compiler IRs ended up being more trouble than its worth.
You want a clear separation between what is language and what is library.
I read this as wanting a different "feeling" for the language. Go uses this approach, with maps and arrays being baked into the syntax, and things work just fine. Implementing Vec in user code is rather the C++ "feeling".
Personally I'm happy Rust took the C++ route, it makes things more interesting, but I can see his point.
Almost all high-level languages have builtin containers. I do think it's a bad fit for Rust (at least for what Rust became), but it's not the end of the world by itself.
The fact that JS has about 3 of them (is it only 3? I'm not sure of this), with different interfaces, and non-usual behavior is what creates problem there. But other languages quite successfully make their own containers either different enough or similar enough that it's not a problem.
> The fact that JS has about 3 of them (is it only 3? I'm not sure of this), with different interfaces, and non-usual behavior is what creates problem there.
V8 has over 35,000 lines of Torque, the DSL for describing these kinds of built-ins. Big chunks of that are dealing with Array methods like splice, sort, from, foreach, etc; and then there is stuff like BigInt, arguments object, a zillion methods on strings.
> Almost all high-level languages have builtin containers.
I don't think that's really true. Maybe for Python and Ruby, and other dynamically typed languages. I dunno about Swift. But it's not really true for Java or C#. Those languages have their collection/containers libraries written in themselves. Java has other problems separating the language from the libraries, but it's not due to collections.
Trust me, you do not want to put this stuff into the compiler. It's not just that it's cheating for perf, but it's confusing to users (no source code to read how these work) and frustrating that they can't write their own. Ultimately what this really means is that these things are indeed written in some language--the compiler's IR. JavaScript actually has a ton of this kind of things and every JS engine has gone through multiple generations of "what language do we write Array.sort in!?". In V8, these intrinsics are written in a DSL because doing them in asm, a special dialect of C++, or one of two compiler IRs ended up being more trouble than its worth.
You want a clear separation between what is language and what is library.