• asx@programming.dev
    link
    fedilink
    arrow-up
    10
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Threads like that twitter thread. Or to put it another way, the community and it’s single minded focus on everything Microsoft produces or endorses and nothing else is frequently off-putting to me.

    I strongly believe there is no “best” in software, or maybe in anything. There is only “best” when you put it in context of your projects and constraints. .NET may very well come out on top in your context, it’s a solid ecosystem. LINQ is great, integration of major functionality comes out of one hand and often just works, you can hire from a large pool of candidates, performance is generally sufficent, I only hear great things from anyone who ever tries F#. The list goes on. I generally think the technology itself is a great general purpose choice and I’ve enjoyed writing C# for my job for a while, as well as for a few side projects.

    But other things have other strengths. For one, the amount of open source library choices is much better. .NET is slowly growing on that front, but I’m still not convinced whether it will ever get to a level of JS or Java, despite sharing almost the same marketshare in case of Java. And frankly, that’s the community that breeds innovation. Lots of things are tried, very little sticks, but in the end you always have options. In .NET you don’t until Microsoft builds something for you.

    Even Microsoft reconizes that:

    There is a perception that other ecosystems (specifically Java, JavaScript, and Python) have more technological diversity and thus an overall stronger open source ecosystem. Historically, we’ve taught customers to expect all the features to come from Microsoft. Since we can’t build everything, especially not at a pace at which other OSS ecosystems evolve, the set of trusted libraries for .NET must grow beyond just Microsoft.

    Getting critical adoption of this model in the .NET ecosystem will likely take years, but the goal for .NET 6 is to create the vision, get buy-in from the .NET Foundation and the open source community at large, as well as getting some of the fundamentals in-place.

    (source: https://github.com/microsoft/dotnet/blob/main/docs/ecosystem-issues.md )

    I am not convinced that this buy in from the open source community exists yet, in particular because Microsoft kept up their antics and showed their hand with things like the hot reload drama or shifting key parts of their products out of open source (pylance, the .NET debugger binaries, key parts of VScode are examples that come to mind).

    And so .NET keeps taking on things that have been proven first elsewhere, behind the innovation curve. For example C# language features such as records or pattern matching. Or integrating open source technologies that become too big to ignore. Hello docker. Hello react integrations. Hello WSL. Hello functioning terminal in Windows, after having lived with the good old cmd for decades.

    But until Microsoft officially starts endorsing and publishing things like that, it’s the worst in other languages when you ask the community. The truth is, other things have other strengths, but if you ask about LINQ and nameof() in Rust you will be disappointed. If you ask for a safe, performant alternative for embedded devices, it’s great (how is .NET doing on embedded ARM these days anyway?).

    And maybe I’m making a problem where there is none. But I want to work with open minded people who focus on results, not tools based on some strange techno-religion. Unfortunately in .NET I often get that vibe. But to be entirely fair, I’ve also seen it in other places, like the functional world (Haskell, or Scala). And it’s slowly getting better in .NET with every integration. So not all hope is lost.

    • MasterBuilder@lemmy.one
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      You speak much truth, but I think ther is more open source than even Microsoft sees in the ecosystem. Getting started producing working projects feels easier in .net to me.

      I was a Java developer in the early days, and found the platform very frustrating. Things started to improve with the spring framework. And when I heard about spring boot, I was very pleased to see that it was all about making a standardized easy initial project startup configuration.

      I recently had to do some Java for the first time and literally decades. I was able to use Java 17.

      I felt it was vastly better than the early days, I was frustrated by things like the incomplete implementation of generics. And it appears that was a direct result of the way Java evolved.

      Unfortunately, it appears many if not most Java projects are still stuck in Java 8 because of all of the Legacy installed code and a lack of decisiveness toward upgrading.

      As for .net, I’m a little worried about some of the things coming out of Microsoft lately. I fear they may be returning to some of their old ways. Time will tell.

    • Pyab@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      We also miss the kind of integrations other eco systems have. Like the good Rust integation with Python. I think the future is to write good memory efficient libraries in Rust and use the from Java, Python,nodejs and .net.

      I am missing a library for the delta format and find it strange that Microsft spent all marketing during build to talk about OneCloud and the delta format and we can’t even use it from .net besides from Synapse.

  • lasagna@programming.dev
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    1 year ago

    Well, like most people who haven’t used .NET, I have very strong opinions about it.

    The first and main issue I take with it is how it’s all capitalised. Second but not less, it’s such a generic name. Am I gonna get websites in the .net domain or do I have to learn Google search beyond typing random junk, pressing enter, and hoping for a stackoverflow answer that works?

    • douglasg14b@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      You’ll eventually get used to different casing conventions in different languages that’s just something that you have to mature into.

      Depending on the language you are writing the conventions will be different, it’s often within your best interests to adopt to those conventions instead of trying to fight against them.

  • happy_piwakawaka@lemmy.nz
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    1 year ago

    NuGet. The whole package management experience just feels so disjointed and tacked sometimes.

    • VS package management is (search, upgrade) slow and buggy
    • Central Package Management works for the CLI but is not implemented properly in VS, and is not available for Framework projects
    • The Azure credential manager, for Azure based NuGet feeds, is hard to configure reliably
    • Don’t even start me on issues querying / publishing NuGet packages via PowerShell
    • nibblebit@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I agree that credential management can be tricky. But genuinely after working from framework to core for over 15 years, publishing an consuming packages has been the best experience for me out of all other ecosystems. Maybe node is easier, but I’ve been burned too many times by supplychain issues to feel safe with it.

      There was a period between 2016-2019 where due to error codes and no error messages it was a bit trickier to resolve the ‘yellow triangle of doom’.

      But honestly compared to pip and cargo and Gradle Nuget has been a damn godsend.

      • happy_piwakawaka@lemmy.nz
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Yeah I agree. Minor frustrations in the grand scheme of things, it’s my top frustration only because I really don’t have any other frustrations with the ecosystem.

        I’d take NuGet over Npm any day, and it’s far far better than the old days of dll hell (I still curse Log4Net).

  • douglasg14b@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    Type system rigidity, I started using TypeScript a lot over the last few years with FE work. TS is so much more flexible and expressive. I really wish that I could express constraints in C# as fluently as I can in TS

    Enums really need more flexibility, unions, discriminated unions, left hand implicit type, better value support…etc

    System.Text.Json still sucks, it’s not greedy, no global setting , non-sane default,no expando support…etc it’s awful to use.

    Unstructured data in general is an absolute pain to work with.

    Composability of tests is still super painful and verbose. Dynamic test generation is awkward and unergonomic. After doing testing and other languages that let you simply compose tests imperatively, C# testing is definitely painful.

    IMHO C# is an acceptable language with an absolutely fantastic framework.

    I love C#, but these are my primary gripes

  • TheCee@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    For me either:

    • Versioning and naming. Framework 4.8.0 -> works down to Windows Server 2012; Framework 4.8.1 -> whoops you need Server 2021. Why.
    • Bugs and regressions in its APIs and tools. Most are related to UI and accessibility as you probably guessed.
    • VS. It has been slow and bug-ridden for a long time now, but just recently I hit that bug where searching text doesn’t find all places. I might have hit it before, but how would you know. It also feels like its tools are sometimes worse than in its previous versions. Suggestions got worse, for sure. But that might come down to my other points.
    • Rather ad hoc, unfocussed language design and the problems that result. Better than many others, but still. Not learning (enough) from the past seems to be a common theme in PL design, but it sure doesn’t help that it isn’t an exact science.
    • Anything UI.
    • douglasg14b@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      TBH I wouldn’t recommend you be building applications in .Net Framework… Most complaints about it have been a solved problem for years with .Net Core/.Net 5+. And there are upgrade paths, at least if you aren’t maintaining WPF/Winforms

      Bugs and regressions? I wonder if that’s for different things than I touch, I’ve had almost no disruptions for the last 9 years. But I’ve mostly worked on console apps and backends. Almost no UI work aside from some WPF and Winforms side projects ages ago.

      • TheCee@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Well, a migration wasn’t an option for our project. But I’ve been trying Windows Forms with .Net 6, but the experience wasn’t that great, either. And it was basic, first-five-minutes stuff like the form designer not opening.

        Microsoft might have announced the end of their own UI story just recently, but to me, it felt always half-assed.

  • kisor@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I am a .NET dev and love the language, ecosystem, tooling and recently their open source initiatives. Few things that frustrate me. Here are my whines:

    • Naming of framework — asp.net core / asp.net could have been one word say, Katana.
    • Language features — I am still comfortable with C#6 or may be a few things from C#7. I know I do not have to use all new stuff, but I feel left out. Too much inertia as of now to get over the hump.
    • I wanted to break into GUI stuff for long time, but there is no clear path. Avalonia is good and I hope the documentation becomes good as explained by Mike in a recent podcast.
    • The company I work for has an initiative of OSP Open Source Practice. I feel bad that .NET/C# is not included in this ever. OSP only means Java, Python and probably Go. It is a nitpick, but MS has done so much to make .NET open source, yet even technology oriented companies think of MS development platform as a closed system.
  • labsin@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    The things I bump in the most:

    • Mutability. Everything is passed by ref so imutable and/or copy should be an important factor of the language, but it’s not. Struct vs class also was way to much impact but can both be used for an interface argument but have such different flow.
    • Compatibility is always favored over improvement in the framework design and language. It has obvious pros as we need less porting, but newer functions in the language are often weird to work with and frameworks get replaced instead of improved, making the porting even harder.
    • A lot of features work magically simple until you want some kind of custom behavior and they then become unmanageable complex. Like the default XML serializer where you can do no extension and everything can get serialized, or async function that abstract the threading untill you want to manage multiple parallel function with error checking and you get very weird and confusing code. Thay all work magically easy as long as you use them for nothing more difficult than the examples.
  • nibblebit@programming.dev
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    Dotnet had really been the ecosystem i keep coming back to. It’s been so frictionless. It could be experience, but I really never feel like I’m fighting with it. Running plain C might be the only other ecosystem that I would hold as a less frictionless experience. I genuinely don’t hold any frustrations with it. I don’t have any ideological problems around Microsoft’s involvement. The tool lets me solve problems effectively.

    The only thing Im missing is a good llvm target for the clr something like what the kotlin native guys enjoy so i can take the ecosystems to new places.

    Sure EFcore can be tiresome and LINQ is inefficiënt. But I’m going to be honest here. If you’re trying to squeeze performance out of an ORM and you’re running up against performance limits of LINQ, maybe not use a time-saving tool as a power tool?

    Maybe I’m simping a bit over it, but I’m not seeing alot of positive content about a tool that has only been very productive in my experience. Maybe because all of the dotnet users are too busy solving actual problems for people haha 😂

    Oh and newtonsoft… And maybe xUnit and nUnit could make up and figure out a way to be ergonomic AND work well multi-threaded.

    • douglasg14b@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Performance limits of LINQ…?

      You’re getting nearly the same performance out of loopes generated by LINQ as you would normal for loops.

      If you’re referring to LINQ and EF Core, you’re generation SQL with it, not running LINQ. And that query generation is incredibly performant these days (I think EF 7 was something like 5% slower than dapper?).

      So luckily you can squeeze a ton of performance out of it!

  • jim_stark@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    To be fair .NET is open source only recently and Avalonia UI is only catching up. More and more people will discover it eventually.

    And Microsoft behaviour is also to be blamed. What is a free and full fledged IDE for .NET? VSCode comes close but is no match to VS.

    And web bros will notice once Blazor hits on. It will though, right?

  • Finone@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    In the documentation they notice the things .NET can do. But they omit the things it can’t do even if you consider them obvious.

  • Irisos@lemmy.umainfo.live
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    More of a VS thing but the fact that you need to have copilot to have a good intellisense experience.

    Let’s say you are defining several JsonPropertyName attributes for your properties, while writing:

    [JsonPropertyName("postId")]
    public int PostId { get; set; }
    

    Base intellisense will propose something completely unrelated for the property while with the github copilot extension, it will automatically recommend the correct property PostId after writing the JsonPropertyName attribute.

    Same thing if you are defining Validators in the same file as the validated object:

    // Post.cs
    
    public class Post ...
    
    public class PostValidator: AbstractValidator<Post> ...
    }
    

    With the copilot extension, after 2 or 3 files, it will automatically propose a validator class for autofill. Default intellisense? You got to type it out manually for every file.

  • F4stL4ne@programming.dev
    link
    fedilink
    arrow-up
    0
    arrow-down
    2
    ·
    edit-2
    1 year ago

    When you have no ethics and just care about results you can also go fishing with dynamite…

    That being said I didn’t know dotnet was now open source. So that’s a good point.