I 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?
The 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
C# 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.
I'm mostly doing Go for work these days, but have been curious about C#.
One problem with Go is the lack of fine-grained control over allocation. In particular, no arena allocation support. How does C# compare?
Another problem is relatively high cost of FFI interop with C. It's gotten better, but Go still needs to switch stacks, etc. How is C#?
How does C# compilation speed compare?
Does the compiler optimize more aggressively than Go (which does very little optimization)? I've heard the C# AOT compiler is lacking, but it's not clear in what way.
Does C# have the equivalent of "go run"?
What's the package management situation like?
Can you use LINQ against databases like Postgres on Linux, without having to buy into a lot of Microsoft/.NET stuff?
> 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.
I couldn't disagree more strongly. This has nothing to do with Windows/Unix and everything to do with language philosophy. I also think that languages that understand that understand they are targeting (text, IDE) rather than just (text) accomplish things that those that only target text never will.
There has been a lot of people in the C# community that think like you - that want to make the C# syntax more minimalist, the code shorter, so that they their microservice code is as terse as they'd write in node or Go.
I think the changes they implemented were a mixed bag. True, they did a lot to clean up the corporatey 'design-pattern' mindset of the API, and some of the syntax is nice.
But there's a lot of stuff I dislike - top level statements are nightmare to use, as they interact weirdly with the rest of the language, implicit usings are just straight up magic in a bad way.
If you're comfortable with the IDE workflow (what's an IDE anyways? everyone's using VS Code/forks and AI nowadays), then it takes care of the boilerplate for you, and it's not an impediment when reading, as your eyes just skip over it.
C# is 25ish years old, and it's a testament to how well-designed it is that it's still used in almost every domain.
Go is an awesome language, but part of its awesomeness comes from the really small feature set, and trying to retrofit Go-like syntax into C# makes the language worse in many ways.
Java comes from UNIX vendor, and C# only exists because Microsoft lost against that UNIX vendor.
Many Linux folks also like to path themselves on the back that Android is Linux, thus UNIX land as well.
Swift and Objective-C also come from UNIX land vendors.
IDEs were invented at Xerox PARC, and companies exploring Lisp Machines.
All 1990's systems, with exception of classical UNIX werr adopting IDEs.
Mac OS, OS/2, BeOS, Solaris, NeXTSTEP, Oberon, Plan 9/Inferno ACME,...
It isn't a Windows only thingy, rather progress.
As someone that was around as UNIX was becoming mainstream, it looks like there is too many idealism going around about what UNIX as OS, and related vendors were all about, before the widespread adoption of GNU/Linux.
I 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.
As 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.
16 comments
[ 4.6 ms ] story [ 35.9 ms ] threadAnd somehow C# has the most sane programming ecosystem
https://github.com/dart-lang/language
https://github.com/orgs/dart-lang/projects/90/views/1
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.
One problem with Go is the lack of fine-grained control over allocation. In particular, no arena allocation support. How does C# compare?
Another problem is relatively high cost of FFI interop with C. It's gotten better, but Go still needs to switch stacks, etc. How is C#?
How does C# compilation speed compare?
Does the compiler optimize more aggressively than Go (which does very little optimization)? I've heard the C# AOT compiler is lacking, but it's not clear in what way.
Does C# have the equivalent of "go run"?
What's the package management situation like?
Can you use LINQ against databases like Postgres on Linux, without having to buy into a lot of Microsoft/.NET stuff?
I couldn't disagree more strongly. This has nothing to do with Windows/Unix and everything to do with language philosophy. I also think that languages that understand that understand they are targeting (text, IDE) rather than just (text) accomplish things that those that only target text never will.
I think the changes they implemented were a mixed bag. True, they did a lot to clean up the corporatey 'design-pattern' mindset of the API, and some of the syntax is nice.
But there's a lot of stuff I dislike - top level statements are nightmare to use, as they interact weirdly with the rest of the language, implicit usings are just straight up magic in a bad way.
If you're comfortable with the IDE workflow (what's an IDE anyways? everyone's using VS Code/forks and AI nowadays), then it takes care of the boilerplate for you, and it's not an impediment when reading, as your eyes just skip over it.
C# is 25ish years old, and it's a testament to how well-designed it is that it's still used in almost every domain.
Go is an awesome language, but part of its awesomeness comes from the really small feature set, and trying to retrofit Go-like syntax into C# makes the language worse in many ways.
Many Linux folks also like to path themselves on the back that Android is Linux, thus UNIX land as well.
Swift and Objective-C also come from UNIX land vendors.
IDEs were invented at Xerox PARC, and companies exploring Lisp Machines.
All 1990's systems, with exception of classical UNIX werr adopting IDEs.
Mac OS, OS/2, BeOS, Solaris, NeXTSTEP, Oberon, Plan 9/Inferno ACME,...
It isn't a Windows only thingy, rather progress.
As someone that was around as UNIX was becoming mainstream, it looks like there is too many idealism going around about what UNIX as OS, and related vendors were all about, before the widespread adoption of GNU/Linux.
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
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/