5 ms·

C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or some

C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or something.

Someone1234 5y ago
They really need to start marking stuff with [Obsolete()] more aggressively. C# has some now outmoded data structures and even keywords. I'd love to see a C#/.Net Standard release that was dedicated to getting rid of things. It may be less exciting in the short term, but it is well past due.
metaltyphoon 5y ago
I agree in a sense but I would do it another way. Either change to the Rust edition equivalent, or simply drop old stuff and keep in the newer bits.
- colejohnson66 5y ago
  There is a Rust edition equivalent in C#…kindof. The csproj file has a property to specify which version of the language you want to use. So if you set it to 9, the compiler won’t allow features from 10 (supposedly; I haven’t tested it).
  - metaltyphoon 5y ago
    I'm aware of <LangVersion> on the csproj but it's opt in system. You opt into the features of the version you want. It never disables anything of the prior versions.
    - colejohnson66 5y ago
      What do you mean “disabling” things from the prior versions?
cogman10 5y ago
Does that make Java the C of managed languages? The great thing about C#/kotlin throwing the kitchen sink at stuff is the good stuff eventually makes it's way into Java.
- pharmakom 5y ago
  (For me at least) life is too short to wait for the best features to trickle down. I mean, most of the interesting Java 17 stuff was surpassed by OCaml in 1995! That’s a 35 year lag!
- azth 5y ago
  I find Java's features to be very well balanced, and only make it into the language after they've been vetted and tested in the wild by other languages. e.g. see their take on concurrency by means of project Loom. No need for async/await and providing separate APIs for sync vs async operations. It has records and sealed types and pattern matching, and is getting destructuring soon.
  - int_19h 5y ago
    .NET async interops nicely with any other language that can do basic callbacks (even C!). How does that work in Loom?
    - cogman10 5y ago
      For VM languages no problem, all those languages will support threads or using threads. For non-VM interopt it will block the carrier thread if a native call causes any sort of blocking. In Java, external to the VM calls are almost non-existent so it's not much of an issue. Likely you'd do those sorts of calls as regular kernel threads instead of the Loom virtual threads.
      - int_19h 5y ago
        To clarify, by interop here I don't just mean calling foreign functions. I mean calling async foreign functions. When async is explicit, it's easy to handle it on ABI level - it's just a bunch of callbacks (or abstractions wrapping them, like tasks/futures). For example, suppose you're writing a Windows desktop app, and you decide to do so in Java. Modern Windows APIs are async. How would you asynchronously invoke such an API? In C#, you'd just use await.
bmitc 5y ago
> I wish they would stick to a smaller set of more powerful features That's basically F#. One can program just using OOP in F#, and it is much more clean and concise.
tonyedgecombe 5y ago
This release in particular feels like they are scratching around to find new features to add.

C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or something.

Someone1234 5y ago

They really need to start marking stuff with [Obsolete()] more aggressively. C# has some now outmoded data structures and even keywords. I'd love to see a C#/.Net Standard release that was dedicated to getting rid of things. It may be less exciting in the short term, but it is well past due.

metaltyphoon 5y ago

I agree in a sense but I would do it another way. Either change to the Rust edition equivalent, or simply drop old stuff and keep in the newer bits.

colejohnson66 5y ago
There is a Rust edition equivalent in C#…kindof. The csproj file has a property to specify which version of the language you want to use. So if you set it to 9, the compiler won’t allow features from 10 (supposedly; I haven’t tested it).
- metaltyphoon 5y ago
  I'm aware of <LangVersion> on the csproj but it's opt in system. You opt into the features of the version you want. It never disables anything of the prior versions.
  - colejohnson66 5y ago
    What do you mean “disabling” things from the prior versions?

cogman10 5y ago

Does that make Java the C of managed languages? The great thing about C#/kotlin throwing the kitchen sink at stuff is the good stuff eventually makes it's way into Java.

pharmakom 5y ago
(For me at least) life is too short to wait for the best features to trickle down. I mean, most of the interesting Java 17 stuff was surpassed by OCaml in 1995! That’s a 35 year lag!
azth 5y ago
I find Java's features to be very well balanced, and only make it into the language after they've been vetted and tested in the wild by other languages. e.g. see their take on concurrency by means of project Loom. No need for async/await and providing separate APIs for sync vs async operations. It has records and sealed types and pattern matching, and is getting destructuring soon.
- int_19h 5y ago
  .NET async interops nicely with any other language that can do basic callbacks (even C!). How does that work in Loom?
  - cogman10 5y ago
    For VM languages no problem, all those languages will support threads or using threads. For non-VM interopt it will block the carrier thread if a native call causes any sort of blocking. In Java, external to the VM calls are almost non-existent so it's not much of an issue. Likely you'd do those sorts of calls as regular kernel threads instead of the Loom virtual threads.
    - int_19h 5y ago
      To clarify, by interop here I don't just mean calling foreign functions. I mean calling async foreign functions. When async is explicit, it's easy to handle it on ABI level - it's just a bunch of callbacks (or abstractions wrapping them, like tasks/futures). For example, suppose you're writing a Windows desktop app, and you decide to do so in Java. Modern Windows APIs are async. How would you asynchronously invoke such an API? In C#, you'd just use await.

bmitc 5y ago

> I wish they would stick to a smaller set of more powerful features That's basically F#. One can program just using OOP in F#, and it is much more clean and concise.

tonyedgecombe 5y ago

This release in particular feels like they are scratching around to find new features to add.