• @douglasg14b
    link
    11
    edit-2
    8 months ago

    I do feel like C# saw C++ and said “let’s do that” in a way.

    One of the biggest selling points about the language is the long-term and cross repo/product/company…etc consistency. Largely the language will be very recognizable regardless of where it’s written and by who it’s written due to well established conventions.

    More and more ways to do the same thing but in slightly different ways is nice for the sake of choices but it’s also making the language less consistent and portable.

    While at the same time important language features like discriminated unions are still missing. Things that other languages have started to build features for by default. C# is incredibly “clunky” in comparison to say Typescript solely from a type system perspective. The .Net ecosystem of course more than makes up for any of this difference, but it’s definitely not as enjoyable to work with the language itself.

    • Thinker
      cake
      link
      fedilink
      8
      edit-2
      8 months ago

      I certainly see where you’re coming from, but I think the designers of C# have done fairly good job evolving the language to balance backwards compatibility, simplicity (in terms of having “only one way” to do things), and the ergonomics expected of modern languages. I think C++ and JS are great comparisons because C++ has at this point added everything and the kitchen sink to it’s language and standard library, whereas C# has gone much more like JS introducing features that evolve the best practices for writing but still feel and read like essentially the same language. For example, primary constructors still look just like regular C#, it’s just a nicer way to define simple POCOs when desired.

      As far as important language features, I think it’s easy to pick on discriminated unions because it seems like C#’s users unanimously want that. However, if you read through proposals and discussions, it’s obvious that there’s a lot of nuance and trade offs in deciding how and what form of discriminated unions should exist in C# (and the designers are very active in working through that nuance and trade off - they said they have a working group that meets weekly to discuss it I believe*). And to be fair, they have introduced a LOT of other important features (like records and the vastly improved pattern matching) in just the last few years. Without those features, discriminated unions wouldn’t be nearly as appealing, and those features are great for the language even without DUs.

      *Edit: Source for my claim is the recent Languages & Runtime Community Standup on the official dotnet YouTube channel. Mads talks about the working group at 21:05, but the discussion of discriminated unions begins at 7:09.

      • @Walnut356
        link
        4
        edit-2
        8 months ago

        the ergonomics expected of modern languages.

        As someone learning c# right now, can we get some of those “modern ergonomics” for switch statements 💀

        I cant believe it works the way it does. “Fallthrough logic is a dumb footgun, so those have to be explicit rather than the default. But C programmers might get confused somehow, so break has to be explicit too”

        I miss fallthrough logic in languages that dont have it, and the “goto case” feature is really sick but like… Cmon, there’s clearly a correct way here and it isnt “there is no default behavior”

        • Thinker
          cake
          link
          fedilink
          1
          edit-2
          8 months ago

          I’m not sure I understand your point about fall through having to be explicit, but I agree that switch statements are lacking ergonomics - which makes some sense considering they were added a looooong time ago. Luckily, they added recently the switch expression, which uses pattern matching and behaves more like Rust’s Match expression. It’s still lacking proper exhuastiveness checks for now, but that’s a problem with the core design of composition in C#’s type model and one they are looking to solve (alongside Discriminate Unions in all likelihood).

          • @Walnut356
            link
            2
            edit-2
            8 months ago

            I’m not sure I understand your point about fall through having to be explicit

            As far as i understand it, every switch statement requires a break otherwise it’s a compiler error - which makes sense from the “fallthrough is a footgun” C perspective. But fallthrough isnt the implicit behavior in C# like it is in C - the absence of a break wouldnt fall through, even if it wasnt a compiler error. Fallthrough only happens when you explicitly use goto.

            But break is what you want 99% of the time, and fallthrough is explicit. So why does break also need to be explicit? Why isnt it just the default behavior when there’s nothing at the end of the case?

            It’s like saying “my hammer that’s on fire isnt safe, so you’re required to wear oven mitts when hammering” instead of just… producing a hammer that’s not on fire.

            From what i saw on the internet, the justification (from MS) was literally “c programmers will be confused if they dont have to put breaks at the end”.

            • Thinker
              cake
              link
              fedilink
              18 months ago

              Ah ok I think I get you now. To be clear, fall through is implicit - when the case being fallen through is empty. I forgot that, if you want to execute some statements in one case, and then go to another case, you need gotos. To be fair, I’ve never needed that behavior before.

              I absolutely see your point on break not being the default. It is sad, although I will say I don’t mind a little extra explicitness in code I’m sharing with a large team.

              • @Walnut356
                link
                18 months ago

                To be clear, fall through is implicit - when the case being fallen through is empty

                That’s even worse… why isnt an empty case a syntax error?

    • TehPers
      link
      fedilink
      English
      18 months ago

      I think one of the things holding back some of the more impactful features we could see in C# is the need to also update the CLR in many cases to handle things like new kinds of types, new kinds of expressions, etc. TypeScript has the benefit of being executed by a dynamic runtime, but C#'s runtime is unfortunately statically typed, meaning it also needs to be updated with the language. It’s also used by multiple languages, for what it’s worth.

      That being said, if they redirected some of their efforts towards improving the CLR as well, I think they could put out all the cool features they’ve mostly sidelined, like DUs and some form of their extension everything proposal.

  • @[email protected]
    link
    fedilink
    English
    58 months ago

    Nice, primary constructors are one of my favorite little QoL features of writing objects in F#. Cool to see it come to C#.

  • @KindaABigDyl
    link
    48 months ago

    I need to get caught up on C#. I stopped using it just before C# 8

    • @douglasg14b
      link
      8
      edit-2
      8 months ago

      The great thing about languages like C# is that you really don’t need to “catch up”. It’s incredibly stable and what you know about C#8 (Really could get away with C# 6 or earlier) is more than enough to get you through the grand majority of personal and enterprise programming needs for the next 5-10 years.

      New language versions are adding features, improving existing ones, and improving on the ergonomics. Not necessarily breaking or changing anything before it.

      That’s one of the major selling points really, stability and longevity. Without sacrificing performance, features, or innovation.

      • @KindaABigDyl
        link
        18 months ago

        Sure, but from what I’ve heard, I’m pretty sure there are a lot of new features that I will want to use :)

  • @[email protected]
    link
    fedilink
    38 months ago

    I’m sure a lot of work went into this, but it seems crazy that we need another way to initialise collections, and another way to make fixed sized arrays.

    I just want less boilerplate.

    • @Lucky
      link
      38 months ago

      The new list initializing syntax is less boilerplate, no?

        • @Lucky
          link
          28 months ago

          This is for custom collections, right? And you don’t even have to use it, you can keep using existing ctors for your custom collections

          Worse case scenario you keep doing what we’ve always had to do. But for the 99% of use cases we get a much more streamlined initializer, with extensions to use our own.

          I don’t see how that’s a bad thing

        • TehPers
          link
          fedilink
          English
          18 months ago

          they actually have to reference the function by string name.

          This is true of a lot of the opt-in language features though, isn’t it? For example, you can just make an .Add method on any IEnumerable type and get collection initializer syntax supported for it, even as an extension method. The same works for Dispose on ref structs I believe, and I remember there being a few other places where this was true (GetAwaiter I think?).

    • @eluvatar
      link
      18 months ago

      I think for arrays it’s not really a benefit. But for other types it’s superior, compared to the current syntax which just calls add on the list object, which is very inefficient compared to building the whole thing at once which is what this new syntax does.