Hacker News Reader

Comment by hvidgaard | Hacker News Reader

I don't like the idea of accessing tuple values by their local name

    var names = LookupName(id);
    WriteLine($"found {names.first} {names.last}.");

It's leaky and should simply use the deconstructing syntax instead.

I'm on the fence about the ref returns. It can lead to some fantastic performance improvements and enable otherwise unusable datastructures. But is C# really a language you want if that is important to you. Why not go all in a use a lib in C or C++ for the critical parts of the code?

I still miss better immutability support, and probably most of all, ability to declare something at non-nullable.

But that said, the update is a fantastic update to an already good language.

View on HN

> But is C# really a language you want if that is important to you.

C# is used by hundreds if not thousands of games by ways of Unity and is therefore demonstrably good enough in this scenario. Furthermore, just because a language is not C++ does not mean you shouldn't take every opportunity to give programmers tools to write fast code - at the end of the day I doubt anyone would be interested in a language that is purposefully slow.

Performance was a core feature of the language (yes, yes, it's managed) from day 1 with unsafe - it's nice to see further improvements in that department.

Use C++ when you need to, definitely, but when you're copying about 256 bytes around for a trivial world-view-projection matrix multiplication[1] you have a problem.

[1]: https://github.com/dotnet/roslyn/issues/10378#issuecomment-2...

While it's used for game development, I'm not convinced that it automatically means features should cater specifically to that audience. Compared to everything non-performance critical the language is used for, the performance crowd is dwarfed. I'm not against it, I personally have been in situations where it would have been useful, I'm just not convinced it's beneficial for the language to implement it.

I watched the NIAC talks yesterday and a quote (paraphrased) that I found interesting was:

> Computation is innovated thanks to gamers.

The same effect might benefit programming languages.

I think that is true. Where they seek to get that last bit of performance, they get creative and come up with new and better ways to do things. But I don't think C# is the language to do this, it lacks too many low level constructs.

Isn't Unity stuck with C# 2.0 ?

Poked around Google and it seems as though you are correct about Unity; however, C# tends to use existing MSIL features and doesn't require the BCL public key token for supporting infrastructure. You can patch in many recent features in by simply defining the types yourself. A common example of that would be:

    public sealed class ExtensionAttribute : Attribute { }

Even async/await comprises of a convention and an interface - I haven't tried it, but in theory using the CLR 2.0 TPL should bring async/await your project. So far as I know, the feature being used for ref returns has always existed for C++/CLR so this stuff should work on CLR 2.0 (although you will need the C# 7.0 compiler).

No, it supports c# 6 without dynamics but uses the 2.0 runtime. Now that mono is open source, they are updating the runtime to be current.

There's a project out there that swaps the mono compiler with Roslyn and gives some nice edit and continue features for Unity.

But those aren't local names, the defaults are 'item1', 'item2', etc. They only get that name if you explicitly declare it in the function declaration.

Reply on news.ycombinator.com