The C# code ends up relying on LINQ, it's interesting how many C# programmers don't even think about that, either anything they work on already uses LINQ or they just reflexively bring it in everywhere they write C#
You'll see that a few of those SO comments actually say they're relying on LINQ to make that work. The array type doesn't have such a method itself.
So, in reality although many C# programmers will think of this as "correct" it just won't even compile... except if there's already LINQ.
There is nothing wrong with System.Linq just like there's nothing wrong with Rust's std::iter::Iterator. If anything, this makes writing Rust use the existing muscle memory if you have C# experience and vice versa.
The performance profile of LINQ, while much maligned, has been steadily improving over the years and, in the example of Sum itself, you actually do want to use it because it will sum faster than open-coded loop[0].
I do have grievances regarding LINQ still - my (non-negotiable) standpoint is that Roslyn (C# compiler) must lower non-escaping LINQ operations to open-coded loops, inline lambdas at IL level and similar, making it zero-cost - .NET (IL compiler/runtime) provides all the tools necessary to match what Rust's zero-cost-ish iterator expressions offer and there just needs to be more political will in the Roslyn teams to do so. Because of this, I'm holding my breath waiting for DistIL[1] to be production-ready which does just that.
(I don't understand what you mean by "it won't compile", because it will, in most cases System.Linq namespace is already referenced anyway, either through global usings or at the top of the file)
> (I don't understand what you mean by "it won't compile", because it will, in most cases System.Linq namespace is already referenced anyway, either through global usings or at the top of the file)
The "in most cases" is doing all the lifting here. Rust's Iterator is in the prelude. Even if you #![no_std] you get the core prelude which has core::iter::Iterator. You would need to explicitly write code to tell Rust "No, I don't want the prelude" to get rid of it, I'm sure people do that, otherwise it wouldn't be possible, but few enough that I've never seen it.
But in C# there is no such promise. In most (but not all) real world C# projects somebody already brought in LINQ. If you're using a technology that gives you a "ready to go" standard C# project template it undoubtedly folds in LINQ too. But it's not actually provided by the language and that's a meaningful gap.
Notably in several of the playground type tools, since LINQ is not there by default this won't work - like I said it won't compile and it doesn't suggest "Oh you need LINQ" because the C# compiler doesn't provide such suggestions.
It's difficult to talk to someone committed to misreading the replies.
LINQ aka IEnumerable/Iterator methods are usually imported by default, something like with prelude. As others said, they are part of standard library.
I'm not sure what you are arguing against either but whatever your criticism is - it is misplaced as C# and Rust roughly belong to the same Venn diagram of features against commonly held beliefs.
You can test it yourself:
sudo apt install dotnet-sdk-8.0
mkdir TestConsole && cd TestConsole
dotnet new console
And then just paste/echo the following to Program.cs:
var numbers = Enumerable.Range(0, 10).ToArray();
var sum = numbers.Sum();
Console.WriteLine(sum);
This will compile. If that's not enough, then it's likely Rust the language is not for you either and you may want to use something like Go for the time being.
LINQ is just part of .NET standard library along with the very collections we are talking about. I'm not sure why one would care about the distinction.
You'll see that a few of those SO comments actually say they're relying on LINQ to make that work. The array type doesn't have such a method itself.
So, in reality although many C# programmers will think of this as "correct" it just won't even compile... except if there's already LINQ.