What .NET 10 GC changes mean for developers

Post by pjmlp » Sun, Oct 05, 2025, 5:26 PM UTC

skydhash wrote: post #122

pjmlp wrote: post #76

Earlier quoted context omitted.

As polyglot developer, I also disagree. If I wanted explicitness for every little detail I would keep writing in Assembly like in the Z80, 80x86, 68000 days. Unfortunately we never got Lisp or Smalltalk mainstream, so we got to metaprogramming with what is available, and it is quite powerful when taken advantage of. Some people avoid wizard jobs, others avoid jobs where magic is looked down upon. I would also add tha…

Explicitness is different than verbosity. Often annotations and the like are abused to create a lot of accidental complexity just to not write a few keywords. In almost every lisp project you'll find that macros are not intended for reducing verbosity, they are there to define common patterns. You can have something like (define-route METHOD PATH BODY) You can then easily expect the generated code. But in Java and ot…

Post by MaXtreeM » Sun, Oct 05, 2025, 5:46 PM UTC

dgllghr wrote: post #55

I am considering dotnet Maui for a project. On the one hand, I am worried about committing to the Microsoft ecosystem where projects like Maui have been killed in the past and Microsoft has a lot of control. Also XML… On the other hand, I’ve been seeing so many impressive technical things about dotnet itself. Has anyone here used Maui and wants to comment on their experience?

Post by CharlieDigital » Sun, Oct 05, 2025, 5:47 PM UTC

devjab wrote: post #141

CharlieDigital wrote: post #62

Earlier quoted context omitted.

You are missing the forest for the trees. C# has increasingly become more terse (e.g. switch expressions, collection initializers, object initializers, etc) and, IMO, is a good balance between OOP and functional[0]. Functions are first class objects in C# and teams can write functional style C# if they want. But I suspect that this doesn't scale well in human terms as we've encountered a LOT of trouble trying to get…

I notice that none of the examples in your blog entry on functional C# deals with error handling. I know that is not the point of your article, but that is actually one of my key issues with C# and its reliance on implicit, because like so many other parts of C# you'd probably hand it over to an exeception handler. I'd much rather prefer you to deal with it explicitly right where it happens, and I would prefer if you…

    > I don't think you should never use OOP or abstractions. I don't think there is a golden rule for when you should use either.

Post by CharlieDigital » Sun, Oct 05, 2025, 6:07 PM UTC

badhombres wrote: post #142

CharlieDigital wrote: post #107

Earlier quoted context omitted.

Would you rather a team move faster and be more productive or be a purist and disallow abstractions to avoid some potential runtime tracing challenges which can be mitigated with good use of OTEL and logging? I don't know about you, but I'm going to bias towards productivity and use integration tests + observability to safeguard code.

Disallow bespoke abstractions and use the industry standard ones instead. People who make abstractions inflate how productive they’re making everyone else. Your user base is much smaller than popular libs, so your docs and abstractions are not as battle tested and easy to use as much as you think.

    await client.Write(
        new ClientWriteRequest(
            [
                // Alice is an admin of form 123
                new()
                {
                    Object = "form:124",
                    Relation = "editor",
                    User = "user:avery",
                },
            ]
        )
    );

    var checkResponse = await client.Check(
        new ClientCheckRequest
        {
            Object = "form:124",
            Relation = "editor",
            User = "user:avery",
        }
    );

    var checkResponse2 = await client.Check(
        new ClientCheckRequest
        {
            Object = "form:125",
            Relation = "editor",
            User = "user:avery",
        }
    );

    await Permissions
        .WithClient(client)
        .ToMutate()
        .Add("alice", "editor", "226")
        .Add("alice", "member", "motion")
        .SaveChangesAsync();

    var allAllowed = await Permissions
        .WithClient(client)
        .ToValidate()
        .Can("alice", "edit", "226")
        .Has("alice", "member", "motion")
        .ValidateAllAsync();

Post by LinXitoW » Sun, Oct 05, 2025, 6:17 PM UTC

osigurdson wrote: post #94

mrsmrtss wrote: post #77

Earlier quoted context omitted.

Don't we have automated tests for catching this kind of things or is everyone only YOLOing in nowadays? Serialization, routing, etc can fail at runtime regardless of using or not using attributes or reflection.

Ease of comprehension is more important than tests for preventing bugs. A highly testable DI nightmare will have more bugs than a simple system that people can understand just by looking at it.