Live data from Hacker News

First C# 7 Design Meeting Notes

github.com

1–10 of 82 posts

Re: First C# 7 Design Meeting Notes

#2
Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;)

But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though.

What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.

Re: First C# 7 Design Meeting Notes

#3

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…

[deleted]

Re: First C# 7 Design Meeting Notes

#5
post #4

If only the open source languages we use had that many resources and paid developers... (Well, technically C# and the related libs are fully OSS now too, IIRC).

They are including almost all the frameworks you would use as well. They weren't set up to take pull requests, and I suspect that they're only interested in bug fixes. So, not entirely genuine.

Re: First C# 7 Design Meeting Notes

#6
post #4

If only the open source languages we use had that many resources and paid developers... (Well, technically C# and the related libs are fully OSS now too, IIRC).

C# isn't "technically" open source, it's just open source. If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here: https://github.com/dotnet/corefx/wiki/Contributing

Re: First C# 7 Design Meeting Notes

#7
post #6
post #4

If only the open source languages we use had that many resources and paid developers... (Well, technically C# and the related libs are fully OSS now too, IIRC).

C# isn't "technically" open source, it's just open source. If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here: https://github.com/dotnet/corefx/wiki/Contributing

IIRC, they (MS) said would steer the language and .NET libs, and not involve a community style effort (because they want to ensure compatibility for their customers), did they change that?

Re: First C# 7 Design Meeting Notes

#8
As a java programmer, who is involved in some large projects that can't be ported, I'm really jealous. And eagerly waiting to see how well the .net core runtime targets linux and mac.

Good, no copy interop with native code would also be awesome. Particularly for machine learning.

Re: First C# 7 Design Meeting Notes

#9
I would LOVE for C# to get language support for go style channels complete with select and friends.

C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~

And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by about 40% :| It feels like in theory it should be compiled down to code with the same efficiency? This is probably more of a CLR/JIT issue though?

Re: First C# 7 Design Meeting Notes

#10
post #9

I would LOVE for C# to get language support for go style channels complete with select and friends. C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~ And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by…

40% is nothing, the last time I tested jquery.each vs a for loop, the for loop was at least 50x faster.
Post reply on HN