Live data from Hacker News

What .NET 10 GC changes mean for developers

roxeem.com

171–180 of 253 posts

Re: What .NET 10 GC changes mean for developers

#171

Earlier quoted context omitted.

My team just recently made the switch from a TS backend to a C# backend for net new work. When we made this switch, we also introduced `ErrorOr`[0] which is a monadic result type. I would not have imagined this to be controversial nor difficult, but it turns out that developers really prefer and understand exceptions. That's because for a backend CRUD API, it's really easy to just throw and catch at a global HTTP pip…

You introduced a pattern that is simply different than the usual in C#. It's also not clearly better, it's different. In languages designed for result types like this the ergonomics of such a type are usually better. All the libraries you use and all methods from the standard library use exceptions. So you have to deal with exceptions in any case. There's also a million or so libraries that implement types like this.…

These are developers that have never written C# before so there's no difference between whether it's language supported or not. It was in the core codebase on day 1 when they onboarded so it may as well have been native.

But what I takeaway from this is that Go's approach to error handling is "also not clearly better, it's different".

Even if C# had core language support for result types, you would be surprised how many developers would struggle with it (that is my takeaway from this experience).

Re: What .NET 10 GC changes mean for developers

#172
post #133

Earlier quoted context omitted.

For me, it will be if they ever get checked errors of some sort. I don’t want to use a language with unchecked exceptions flying about everywhere. This isn't saying I want checked exceptions either, but I think if they get proper unions and then have some sort of error union type it would go a long way.

You can get an error union now: https://github.com/amantinband/error-or

The issue is the ecosystem and standard library. They still will be throwing unchecked exceptions everywhere

Re: What .NET 10 GC changes mean for developers

#173

Earlier quoted context omitted.

You introduced a pattern that is simply different than the usual in C#. It's also not clearly better, it's different. In languages designed for result types like this the ergonomics of such a type are usually better. All the libraries you use and all methods from the standard library use exceptions. So you have to deal with exceptions in any case. There's also a million or so libraries that implement types like this.…

These are developers that have never written C# before so there's no difference between whether it's language supported or not. It was in the core codebase on day 1 when they onboarded so it may as well have been native. But what I takeaway from this is that Go's approach to error handling is "also not clearly better, it's different". Even if C# had core language support for result types, you would be surprised how m…

If you're not coming from a strongly typed functional language, it's still a pattern you're not used to. Which might be a bit of a roundabout way to say that I agree about your last part, developers without contact to that kind of language will struggle at first with a pattern like this.

I know how to use this pattern, but the C# version still feels weird and cumbersome. Usually you combine this with pattern matching and other functional features and the whole thing makes it convenient in the end. That part is missing in C#. And I think it makes a different in understanding, as you would usually build ony our experience with pattern matching to understand how to handle this case of Result|Error.

Re: What .NET 10 GC changes mean for developers

#174
post #167
post #144

Earlier quoted context omitted.

Classic HN comment with unapologetic statements. If Flutter were that good, it wouldn't have flatlined so fast after the initial hype a few years ago. I tried it last year, only to see rendering glitches in the sample project.

28% of new iOS apps are made with flutter and it's the #1 cross platform framework on stack overflow 2024 survey so I highly doubt it has flatlined. https://flutter.dev/multi-platform/ios https://survey.stackoverflow.co/2024/technology#1-other-fram...

All those stats look great on paper, but a few months ago I checked job postings for different mobile frameworks, and Flutter listings were 2-3 times fewer than RN. Go on Indeed and see for yourself.

For a "28% of new iOS apps", the Flutter subreddit is a ghost town with regular "is it dying? should I pick RN?" posts. I just don't buy the numbers because I'm myself in a rather stagnant cross-platform ecosystem, so I know this vibe well.

If I ever leave .NET, no way I'd move to something like Flutter. Even Kotlin Multiplatform is more promising concept-wise. LLMs are changing cross-platform development and Flutter's strong sides are not that important anymore, while its weak sides are critical.

Re: What .NET 10 GC changes mean for developers

#175
post #149
post #27

A hobby audio and text analysis application I've written, with no specific concern for low level performance other than algorithmically, runs 4x as fast in .net10 vs .net8. Pretty much every optimization discussed here applies to that app. Great work, kudos to the dotnet team. C# is, imo, the best cross platform GC language. I really can't think of anything that comes close in terms of performance, features, ecosyste…

Java? Is supported on more platforms, has more developers, more jobs, more OSS projects, is more widely used (Tiobe 2024). Performance was historically better, but c# caught up.

Reified generics, value types, LINQ are just a few things that you would miss when going to Java. Also Java and .NET are both big, that's not a real argument here. Not that I would trust Tiobe index too much, but as of 2025 September C# is right behind Java at 5th place.

Re: What .NET 10 GC changes mean for developers

#176

Earlier quoted context omitted.

These are developers that have never written C# before so there's no difference between whether it's language supported or not. It was in the core codebase on day 1 when they onboarded so it may as well have been native. But what I takeaway from this is that Go's approach to error handling is "also not clearly better, it's different". Even if C# had core language support for result types, you would be surprised how m…

If you're not coming from a strongly typed functional language, it's still a pattern you're not used to. Which might be a bit of a roundabout way to say that I agree about your last part, developers without contact to that kind of language will struggle at first with a pattern like this. I know how to use this pattern, but the C# version still feels weird and cumbersome. Usually you combine this with pattern matching…

    > Usually you combine this with pattern matching and other functional features and the whole thing makes it convenient in the end. That part is missing in C#
You mean like this?

    string foo = result.MatchFirst(
        value => value,
        firstError => firstError.Description);
Or this?

    ErrorOr foo = result
        .Then(val => val * 2)
        .Then(val => $"The result is {val}");
Or this?

    ErrorOr foo = await result
        .ThenDoAsync(val => Task.Delay(val))
        .ThenDo(val => Console.WriteLine($"Finsihed waiting {val} seconds."))
        .ThenDoAsync(val => Task.FromResult(val * 2))
        .ThenDo(val => $"The result is {val}");
With pattern matching like this?

    var holidays = new DateTime[] {...};
    var output = new Appointment(
        DayOfWeek.Friday, 
        new DateTime(2021, 09, 10, 22, 15, 0), 
        false
    ) switch
    {
        { SocialRate: true } => 5,
        { Day: DayOfWeek.Sunday } => 25,
        Appointment a when holidays.Contains(a.Time) => 25,
        { Day: DayOfWeek.Saturday } => 20,
        { Day: DayOfWeek.Friday, Time.Hour: > 12 } => 20,
        { Time.Hour: = 18 } => 15,
        _ => 10,
    };
C# pattern matching is pretty damn good[0] (seems you are not aware?).

[0] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

Re: What .NET 10 GC changes mean for developers

#177

Earlier quoted context omitted.

If you're not coming from a strongly typed functional language, it's still a pattern you're not used to. Which might be a bit of a roundabout way to say that I agree about your last part, developers without contact to that kind of language will struggle at first with a pattern like this. I know how to use this pattern, but the C# version still feels weird and cumbersome. Usually you combine this with pattern matching…

> Usually you combine this with pattern matching and other functional features and the whole thing makes it convenient in the end. That part is missing in C# You mean like this? string foo = result.MatchFirst( value => value, firstError => firstError.Description); Or this? ErrorOr foo = result .Then(val => val * 2) .Then(val => $"The result is {val}"); Or this? ErrorOr foo = await result .ThenDoAsync(val => Task.Dela…

None of your examples use native C# pattern matching. And without language support like e.g. discriminated unions you can't have exhaustive pattern matching in C#. So you'll have to silence the warnings about the missing default case or always add one, which is annoying.

Re: What .NET 10 GC changes mean for developers

#178
post #48

Earlier quoted context omitted.

I am paid to work in Java and C# among Go, Rust, Kotlin, Scala and I wholeheartedly agree. I hate the implicitness of Spring Boot, Quarkus etc. as much as the one in C# projects. All these magic annotations that save you a few lines of code until they don't, because you get runtime errors due to incompatible annotations. And then it takes digging through pages of docs or even reporting bugs on repos instead of just f…

I disagree on this. I am at a (YC, series C) startup that just recently made the switch from TS backend on Nest.js to C# .NET Web API[0]. It's been a progression from Express -> Nest.js -> C#. What we find is that having attributes in both Nest.js (decorators) and C# allows one part of the team to move faster and another smaller part of the team to isolate complexity. The indirection and abstraction are explicit deci…

> so that 90% of the devs simply need to "follow the pattern" and 10% of the devs can focus on more complex logic backing those attributes and decorators.

Works well until the 10% that understand the behind the scenes leave and you are left with a bunch of developers copy and pasting magic patterns that they don't understand.

I love express because things are very explicit. This is the JSON schema being added to this route. This route is taking in JSON parameters. This is the function that handles this POST request endpoint.

I joined a team using Spring Boot and the staff engineer there couldn't tell me if each request was handled by its own thread or not, he couldn't tell me what variables were shared across requests vs what was uniquely instantiated per request. Absolute insanity, not understanding the very basics of one's own runtime.

Meanwhile in Express, the threading model is stupid simple (there isn't one) and what is shared between requests is obvious (everything declared in an outer scope).

Re: What .NET 10 GC changes mean for developers

#179

Earlier quoted context omitted.

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.

This is raw OpenFGA code: 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 = "ed…

In the first example, I have to learn and understand OpenFGA, in the second example I have to learn and understand OpenFGA and your abstractions.

Re: What .NET 10 GC changes mean for developers

#180

Earlier quoted context omitted.

If purity is a requirement for "real" functional programming, then OCaml or Clojure aren't functional. Regarding totality, even Haskell has partial functions and exceptions.

Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.

What is an example of a real functional language for you?
Post reply on HN