Hacker News Reader

Comment by simonask | Hacker News Reader

C# is an odd one. It's surprisingly flexible, but then oddly lacking in other areas. Quite productive, but also quite inconsistent and uncomposable.

Once you've tried a better type system (Rust), it's difficult to go back to C#. People jump through all kinds of hoops to get good performance out of it, and they're mostly able to.

Things I dearly miss from Rust when I'm using C#:

- Associated types in interfaces. (IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance.)

- Move-only structs. (Currently, every type with value semantics is trivially copyable, even ref structs.)

View on HN

"IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance."

Foreach loops use compile-time duck typing, so if you don't intend to use your enumerable in LINQ then both the enumerable and enumerator don't need to implement any interfaces.

This optimisation covers only one common use case, but that's the way of things in C# land.

IEnumerators can also be value types So no heap allocation, just stack.

slightly off topic but a lot of things in .NET actually use compile time duct typing. like how async works To make your own task, you don't add an interface to it. You just implement a single method.

I’m aware. I would consider the fact that LINQ has caveats a failure of language design - it’s so convenient, but you just can’t use it for performance-sensitive stuff.

Meanwhile, iterators in Rust frequently outperform manual loops.

ZLinq exists: https://github.com/Cysharp/ZLinq

    > Zero allocation LINQ with LINQ to Span, LINQ to SIMD, and LINQ to Tree (FileSystem, JSON, GameObject, etc.) for all .NET platforms and Unity, Godot.

Yup, I’m a happy user of it. Writing generic code with these enumerators is extremely verbose, because the language lacks associated types.

>- Associated types in interfaces. (IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance.)

Its not but if you call from the interface and not the implementation, it has to box because that's the contract. If you for each over a List<T> and not IEnumerable you get a stack allocated value type IEnumerator.

Devirtualization as a (JIT) compile-time optimization is possible in an increasing number of common cases, and I can think of few cases where I'd choose to explicitly consume a non-generic IEnumerable over a non-type-erased IEnumerable<T>.

Optimizations like that is not a sound basis for an architecture, though.

Like, I get that it’s “fine” for a lot of things, but it’s very not fine in situations where you really need to guarantee that a particular operation doesn’t, say, trigger GC, like in a video game.

I have a series of proposal for most/all of these.

Associated types: https://github.com/dotnet/csharplang/issues/8712

Ownership: https://github.com/agocke/csharplang/blob/ownership/proposal...

Reply on news.ycombinator.com