3 ms·

If you do have useful feedback, please submit an issue or contribute a PR to dotnet/runtime. That’s how many performance improvements in LINQ come to be, that t

If you do have useful feedback, please submit an issue or contribute a PR to dotnet/runtime. That’s how many performance improvements in LINQ come to be, that the post discusses.

louthy 2y ago
7 years ago: https://github.com/dotnet/csharplang/issues/1060 https://github.com/dotnet/csharplang/issues/1060 3 years ago: https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-07.md#cost-free-delegates-and-linq https://github.com/dotnet/csharplang/blob/main/meetings/2021... I've given up submitting to csharplang now. It seemed like a positive when it was first open-sourced, but the proposals/issues are often just circular discussions that go nowhere. It doesn't feel like (at least from the outside) any proposal by a non-MS employee would make it thru the process unless MS needed it themselves. Which is what I was alluding to in my original post. I may well be wrong and maybe some proposals have made it through, but it feels like an illusion of community collaboration rather than actual community collaboration imho. I don't expect preferential treatment or anything like that, but it would be good if one of the most standout features of C# got some proper attention after a decade of neglect. There has been a lot of effort on performance in many areas of the framework and the language. Leveraging that work for LINQ (the language feature) would be very welcome.
- neonsunset 2y ago
  C# is already big enough language. This is more about .NET in general and less about C# specifically. From what I've heard - there is an awareness that the current cost of delegates, while not that problematic anymore, can be improved. Whether this happens via explicit syntax to enable (ref) struct closures and value delegate pattern implementations or via object escape analysis and better devirtualization remains to be seen. p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead.
  - louthy 2y ago
    > p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead. Ah the standard "why don't you just use F#" line. I have a standard response to that now ;) https://github.com/louthy/language-ext/wiki/%22Why-don't-you-just-use-F%23%3F%22 https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
    - neonsunset 2y ago
      Thanks, I did read the reply before but remain skeptical. The reason for this is "strictly-managed" teams are also often resistant to libraries in a similar way. Fully adopting a high-end solution like LanguageExt can be seen as significant commitment. If a business case justifies that, it means that adopting F# could be on the table too. And unlike Haskell, integrating "functional core" into existing .NET solutions is very easy and has low amount of friction, much less so than people tend to assume upon hearing the suggestion.
andy81 2y ago
The C# experience already got rug-pulled with Dev Kit. I'm not going to spend time working for free on tools that MS charges a subscription to use.
- neonsunset 2y ago
  You are confusing devkit, which uses vs license, with base C# extension which is free. Also https://news.ycombinator.com/item?id=41884187 https://news.ycombinator.com/item?id=41884187 https://news.ycombinator.com/item?id=41809351 https://news.ycombinator.com/item?id=41809351 https://news.ycombinator.com/item?id=41639205 https://news.ycombinator.com/item?id=41639205 https://news.ycombinator.com/item?id=41384888 https://news.ycombinator.com/item?id=41384888
  - andy81 2y ago
    Nobody complaining about Dev Kit would be unaware of the base C# extension.

If you do have useful feedback, please submit an issue or contribute a PR to dotnet/runtime. That’s how many performance improvements in LINQ come to be, that the post discusses.

louthy 2y ago

7 years ago: https://github.com/dotnet/csharplang/issues/1060 https://github.com/dotnet/csharplang/issues/1060 3 years ago: https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-07.md#cost-free-delegates-and-linq https://github.com/dotnet/csharplang/blob/main/meetings/2021... I've given up submitting to csharplang now. It seemed like a positive when it was first open-sourced, but the proposals/issues are often just circular discussions that go nowhere. It doesn't feel like (at least from the outside) any proposal by a non-MS employee would make it thru the process unless MS needed it themselves. Which is what I was alluding to in my original post. I may well be wrong and maybe some proposals have made it through, but it feels like an illusion of community collaboration rather than actual community collaboration imho. I don't expect preferential treatment or anything like that, but it would be good if one of the most standout features of C# got some proper attention after a decade of neglect. There has been a lot of effort on performance in many areas of the framework and the language. Leveraging that work for LINQ (the language feature) would be very welcome.

neonsunset 2y ago
C# is already big enough language. This is more about .NET in general and less about C# specifically. From what I've heard - there is an awareness that the current cost of delegates, while not that problematic anymore, can be improved. Whether this happens via explicit syntax to enable (ref) struct closures and value delegate pattern implementations or via object escape analysis and better devirtualization remains to be seen. p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead.
- louthy 2y ago
  > p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead. Ah the standard "why don't you just use F#" line. I have a standard response to that now ;) https://github.com/louthy/language-ext/wiki/%22Why-don't-you-just-use-F%23%3F%22 https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
  - neonsunset 2y ago
    Thanks, I did read the reply before but remain skeptical. The reason for this is "strictly-managed" teams are also often resistant to libraries in a similar way. Fully adopting a high-end solution like LanguageExt can be seen as significant commitment. If a business case justifies that, it means that adopting F# could be on the table too. And unlike Haskell, integrating "functional core" into existing .NET solutions is very easy and has low amount of friction, much less so than people tend to assume upon hearing the suggestion.

andy81 2y ago

The C# experience already got rug-pulled with Dev Kit. I'm not going to spend time working for free on tools that MS charges a subscription to use.

neonsunset 2y ago
You are confusing devkit, which uses vs license, with base C# extension which is free. Also https://news.ycombinator.com/item?id=41884187 https://news.ycombinator.com/item?id=41884187 https://news.ycombinator.com/item?id=41809351 https://news.ycombinator.com/item?id=41809351 https://news.ycombinator.com/item?id=41639205 https://news.ycombinator.com/item?id=41639205 https://news.ycombinator.com/item?id=41384888 https://news.ycombinator.com/item?id=41384888
- andy81 2y ago
  Nobody complaining about Dev Kit would be unaware of the base C# extension.