In C++, until C++20’s std::span, you would just use std::vector for stuff you can modify and const std::vector for stuff you can’t. I think the real problem is

In C++, until C++20’s std::span, you would just use std::vector for stuff you can modify and const std::vector for stuff you can’t. I think the real problem is that Go’s type system doesn’t catch the common error of keeping a reference to something you don’t own, or similar errors. C# catches some of these errors by letting you return a IReadOnlyList<T> or some other restricted type. Golang has ways to narrow certain types, but the slice type is primitive and has no narrowed read-only variation. C# instead forces you to pay a higher runtime cost, because you’re paying a lot more for indirection with IReadOnlyList<T>. People fret about the difference between T[] and List<T> in C#, and they do come with different performance characteristics… Go’s choice to use slices everywhere does have a certain advantage that you’re getting the fast path everywhere, and you’re spending less time thinking about which one to use. Not trying to say that Go is “right” here, it’s just my viewpoint that these language design decisions are rational.