Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What .NET 10 GC changes mean for developers

roxeem.com

Post reply on HN
Print view View original

211–220 of 253 posts

Re: What .NET 10 GC changes mean for developers

#211

Post by throw954387543 »

physPop wrote: post #196
munchler wrote: post #88

Earlier quoted context omitted.

Except for F#, which also gets all the .NET10 cross-platform GC improvements for free and is a better programming language than C#.

+1 F# is criminally under-used

I've used it, and am still using it, to generate lots of value in a very large org. Having a language where I can bring Go, Node, etc developers over and get relatively better performance without having to teach OOP and all the implicit conventions that are on the C# side is a bit like a cheat code. With modern .NET, its better than Java perf, with better GC, and having the ability to code generic Python/JS looking code whilst still having type checking (HM inference). There are C# libraries we do use but with standard templates for those few with patterns to interface to mostly F# layers you can get very far in a style of code more fitting of a higher more dynamic language. Ease of use vs perf, its kind of in the middle - and it has also benefited from C# features (e.g. spans recently)

Its not one feature with F# IMO, its little things that add up which generally is the reason it is hard to convince someone to use it. To the point when the developers (under my directive) had to write two products in C# they argued with me to switch back.

Re: What .NET 10 GC changes mean for developers

#212

Post by honkostani »

whizzter wrote: post #187
honkostani wrote: post #104

I always found that Jit and GC are a marriage destined to come together, but never found one another entirely. Jit marks the hotloop in code- and thus can tell the GC in detail what a generation really is and how long a generation lifetime really lasts. It can reveal secret cull conditions for long generational objects. If that side-branch is hit in the hot-loop, all longterm objects of that generation, are going to…

Any interpreter could theoretically do those "marking" things, also JIT's do far more than just "bytecompile" hot loops, _all_ cooperative modern GC's are enabled by JIT semantics for things like read and/or write barriers (this helps a GC keep track of objects that keep getting "touched" whilst the GC can work in parallel). Outside of the mentioned, things like detecting finegrained lifetimes is very very hard and t…

[dead]

Re: What .NET 10 GC changes mean for developers

#213

Post by npodbielski »

debugnik wrote: post #60
npodbielski wrote: post #53

Earlier quoted context omitted.

What are those magic annotations you are talking about? Attributes? Not much of those are left in modern .net.

Attributes and reflection are still used in C# for source generators, JSON serialization, ASP.NET routing, dependency injection... The amount of code that can fail at runtime because of reflection has probably increased in modern C#. (Not from C# source generators of course, but those only made interop even worse for F#-ers).

OK lets brake this down:

- code generators, I think I saw it only in regex. Logging can be done via `LoggerDefine` too so attributes are optional. Also code generators have access to full tokenized structure of code, and that means attributes are just design choice of this particular generator you are using. And finally code generators does not produce runtime errors unless code that they generated is invalid.

- Json serialization, sure but you can use your own converters. Attributes are not necessary.

- asp.net routing, yes but those are in controllers, my impression is that minimal APIs are now the go to solution and you have `app.MapGet(path)` so no attributes; you can inject services into minimal APIs and this does not require attributes. Most of the time minimal APIs does not require attributes at all.

- dependency injection, require attributes when you inject services in controllers endpoints, which I never liked nor understood why people do that. What is the use case over injecting it through controller constructor? It is not like constructor is singleton, long living object. It is constructed during Asp.net http pipeline and discarded when no longer necessary.

So occasional usage, may still occur from time to time, in endpoints and DTOs (`[JsonIgnore]` for example) but you have other means to do the same things. It is done via attributes because it is easier and faster to develop.

Also your team should invest some time into testing in my opinion. Integration testing helps a lot with catching those runtime errrors.

Re: What .NET 10 GC changes mean for developers

#214

Post by mexicocitinluez »

devjab wrote: post #45
adzm wrote: 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…

Having worked with C# professionally for a decade, going through the changes with LINQ, async/await, Roslyn, and the rise of .NET Core, to .NET Core becoming .NET, I disagree. I certainly think that C# is a great tool and that it’s the best it has ever been. It’s also relies on very implicit behaviour, it is build upon OOP design principles and a bunch of “needless” abstraction. Things I personally have come to view…

> Similar to how Uncle Bob will always be correct when he calls teams out for getting his principles wrong.

Is this sarcasm?

Re: What .NET 10 GC changes mean for developers

#215

Post by Hendrikto »

physPop wrote: post #195
Xss3 wrote: post #44

Earlier quoted context omitted.

Lmao, functional programming is far from ergonomic

honestly this sounds like you've never really done it. FP is much better for ergonomics, developer productivity, correctness. All the important things when writing code.

I like FP, but your claim is just as baseless as the parent’s.

If FP was really better at “all the important things”, why is there such a wide range of opinions, good but also bad? Why is it still a niche paradigm?

Re: What .NET 10 GC changes mean for developers

#216

Post by mexicocitinluez »

branko_d wrote: post #203
feoren wrote: post #200

Earlier quoted context omitted.

I have been coding in C# for 16 years and I have no idea what you mean by "hidden indirection and runtime magic". Maybe it's just invisible to me at this point, but GC is literally the only "invisible magic" I can think of that's core to the language. And I agree that college-level OOP principles are an anti-pattern; stop doing them. C# does not force you to do that at all, except very lightly in some frameworks wher…

Some examples: - Attributes can do a lot of magic that is not always obvious or well documented. - ASP.NET pipeline. - Source generators. I love C#, but I have to admit we could have done with less “magic” in cases like these.

I don't really consider any of these magic, particularly source generators.

It's just code that generates code. Some of the syntax is awkward, but it's not magic imo.

Re: What .NET 10 GC changes mean for developers

#217

Post by mexicocitinluez »

skydhash wrote: post #118
CharlieDigital wrote: post #109

Earlier quoted context omitted.

C# source generators are...just macros?

They are not. They are generators. Macros tends to be local and explicit as the other commenters have said. They are more like templates. Generators can be fairly involved and feels like a mini language, one that is not as observable as macros.

> Generators can be fairly involved and feels like a mini language, one that is not as observable as macros.

I agree the syntax is awkward, but all it boils down to is concatenating code in strings and adding it as a file to your codebase.

And the syntax will 100% get cleaner (it;s already happening with stuff like ForAttributeWithMetadataName

Re: What .NET 10 GC changes mean for developers

#218

Post by Hendrikto »

mexicocitinluez wrote: post #214
devjab wrote: post #45

Earlier quoted context omitted.

Having worked with C# professionally for a decade, going through the changes with LINQ, async/await, Roslyn, and the rise of .NET Core, to .NET Core becoming .NET, I disagree. I certainly think that C# is a great tool and that it’s the best it has ever been. It’s also relies on very implicit behaviour, it is build upon OOP design principles and a bunch of “needless” abstraction. Things I personally have come to view…

> Similar to how Uncle Bob will always be correct when he calls teams out for getting his principles wrong. Is this sarcasm?

I think this is fair criticism. OOP advocates like Uncle Bob always try to sell you 100 often contradictory and ill-defined rules and guidelines for how to “use it right”. Stuff like

* objects should model a single concept, or

* every domain concept should be an object.

These two alone are already contradictory. And what do they even mean? Concretely?

Then, when OOP invariably breaks down, they can always point to any of the 100 rules that you supposedly violated, and blame the failure on that. “Yes, it did not work out because you did not do it right.” It’s the true scotsman fallacy.

It’s like communism. It would work out if somebody just finally did it properly.

Maybe a system that requires 100 hard to follow rules to have even a chance at success just isn’t a great one.

Re: What .NET 10 GC changes mean for developers

#219

Post by debugnik »

npodbielski wrote: post #213
debugnik wrote: post #60

Earlier quoted context omitted.

Attributes and reflection are still used in C# for source generators, JSON serialization, ASP.NET routing, dependency injection... The amount of code that can fail at runtime because of reflection has probably increased in modern C#. (Not from C# source generators of course, but those only made interop even worse for F#-ers).

OK lets brake this down: - code generators, I think I saw it only in regex. Logging can be done via `LoggerDefine` too so attributes are optional. Also code generators have access to full tokenized structure of code, and that means attributes are just design choice of this particular generator you are using. And finally code generators does not produce runtime errors unless code that they generated is invalid. - Json…

> Json serialization, sure but you can use your own converters

And going through converters is (was?) significantly slower for some reason than the built-in serialisation.

> my impression is that minimal APIs are now the go to solution and you have `app.MapGet(path)` so no attribute

Minimal APIs use attributes to explicitly configure how parameters are mapped to the path, query, header fields, body content or for DI dependencies. These can't always be implicit, which BTW means you're stuck in F# if you ever need them, because the codegen still doesn't match what the reflection code expects.

I haven't touched .NET during work hours in ages, these are mostly my pains from hobbyist use of modern .NET from F#. Although the changes I've seen in C#'s ecosystem the last decade don't make me eager to use .NET for web backends again, they somehow kept going with the worst aspects.

I'm fed up by the increasing use of reflection in C#, not the attributes themselves, as it requires testing to ensure even the simplest plumbing will attempt to work as written (same argument we make for static types against dynamic, isn't it?), and makes interop from F# much, much harder; and by the abuse of extension methods, which were the main driver for implicit usings in C#: no one knows which ASP.NET namespaces they need to open anymore.

Re: What .NET 10 GC changes mean for developers

#220

Post by germandiago »

skydhash wrote: post #139
germandiago wrote: post #138

Earlier quoted context omitted.

This is the trade-off with macros and annotation/code-generation systems. I tend to do obvious things whwn I use this kind of tools. In fact, I try to avoid macros. Even if configurability is not important, I favor sinplification over reuse. In case I need reuse, I go for higher order functions if I can. Macro is the last bullet. In some circumstances like Json or serialization maybe they can be slightly abused to ma…

IMO, macros and such should be to improve coding UX. But using it for abstractions and the like is very much not worth it. So something like JSX (or the loop system in Common Lisp) is good. But using it for DI is often a code smell for me.

> IMO, macros and such should be to improve coding UX

Coding UX critically leans on familiarity and spread of knowledge. By definition, making a non-obvious macro not known by others makes the UI just worse for a definition of worse which means "less manageable by anyone that looks at it without previous knowledge".

That is also the reason why standard libraries always have an advantage in usability just because people know them or the language constructs themselves.

Post reply on HN