6 ms·
C# Language Design Meeting for June 30th, 2025
- jasonthorsness 1y agoI always enjoy reading the language design committee notes (this is the latest one). C# has the most open and collaborative development process I am aware of. Do any other languages progress like this?
- tester756 1y agoProbably they're the only one among mainstream languages And somehow C# has the most sane programming ecosystem
- pjmlp 1y agoIf we leave out the desktop programming framework schizophrenia from Redmond.
- mdhb 1y agoDart is also absolutely fantastic in this regard. https://github.com/dart-lang/language https://github.com/dart-lang/language https://github.com/orgs/dart-lang/projects/90/views/1 https://github.com/orgs/dart-lang/projects/90/views/1
- sakesun 1y agoPython, Kotlin
- legobmw99 1y agoThe python PEP process is fairly open, most of the discussion ends up happening on public facing boards. I don’t think they have regularly scheduled meetings to consolidate decisions, though
- monocularvision 1y agoSwift
- brainzap 1y agoGo has a repo with all discussions. the discussion about the package file format (go.mod) is very inspiring
- pjmlp 1y agoJava mailing lists since forever, initially JSR process, nowadays JEP.
- jeswin 1y agoC# is a fantastic language, and with NativeAOT it can become a real alterntive to Go. It "can"; but most likely it won't. The problem with C# is that its design decisions won't attract any new users who are considering or using Go (or in some cases Rust). That's a consequence perhaps of listening to its users, who are mostly Windows-based and have rigid preferences. And then on the other hand, C# goes on to introduce excellent functional-style abilities - while at the same time handicapping them in some way. Recently, on one of their GH issues I was arguing that it's a good idea to reduce typing and allow namespace inference from directory structures/paths - given that most projects already have them in sync (and it can be done in a non-breaking way). In general, I felt that the community feels that it should be solved with "IDE features". Pushing these into an IDE is the Windows way of doing things. To win in Unix land, C# needs to be editable in a plain text editor. It requires succinctness. But with the current community, I'm afraid they'll never figure this out.
- rjbwork 1y ago>But with the current community, I'm afraid they'll never figure this out. I hope that remains the case. File structure inferred namespacing to save one line per file seems like a ridiculous breaking change. If you're looking for succinctness to the level that something like that matters in your line/character count, use Perl or something. If you're looking for something like scripting without a lot of fanfare, just look at https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
- glimshe 1y agoI never understood people who advocate radical succinctness so typing a program is optimal when most programming time is spent in reading documentation and debugging.
- jeswin 1y agoIt's not radical succintness. I just like to write pure functions. C# embraces many fp idioms, but in the end makes it hard to use them without a lot of ceremony. So what I see is a very capable language, with generics far ahead of golang, but a pain to write because I need to nest them inside namespaces and classes. If you take the HN crowd for instance (which is what a lot of startups are like), nobody wants to write Java-style OOP. C# can simplify it quite a bit (retaining full backward compat), but likely won't.
- bob1029 1y agoI like the type parameter inference from constraints proposal. I've been adopting these new approaches into my code gradually over time by way of intellisense suggestions. Sometimes I'll see the little ... in front and think "what the hell, let's see". If it looks ugly, it's easy enough to back out. Some things took a while to grow on me. So far the only newish thing I haven't preferred much is the range operator syntax [0]. Every time I accept that one its a quick revert to the more verbose indexing operators. [0] https://github.com/dotnet/csharplang/discussions/198 https://github.com/dotnet/csharplang/discussions/198
- louthy 1y agoAs the author of language-ext [1] (functional programming library for C#) -- these suggestions are a big "YES!!!!!" from me. I assume they're doing the first one due to the way they're using static interfaces like traits (which is what I also do to support Functor, Applicative, Monad, etc. traits). Being able to refine the type-checker based on constraints would be a huuuge win. Although, I'd prefer higher-kinds :) The second one has been a big ballache when using pattern-matching. I think the leading `.` on the patterns isn't pretty, but I'd take it over handwriting the full type name every time. [1] https://github.com/louthy/language-ext/ https://github.com/louthy/language-ext/
- ctenb 1y agoSorry to go tangential, I was reading your blog posts following the link from your post. The monoid example is possible without static interface methods: you could use the new() constraint and have the empty constructor act as identity element. Kudos on the posts, very nice to read.
- louthy 1y agoTrue! (Although that requires an allocation) The technique works best for encoding higher-kinded traits and, as you say, Monoid doesn’t need any of that, but it was an easy way to introduce the ideas.
- chris_pie 1y agoThe second one seems very similar to the "using static" feature, but less verbose.