Earlier quoted context omitted.
> C# is, imo, the best cross platform GC language. I really can't think of anything that comes close How about F#? Isn't F# mostly C# with better ergonomics?
Lmao, functional programming is far from ergonomic
What .NET 10 GC changes mean for developers
71–80 of 253 posts
Re: What .NET 10 GC changes mean for developers
#72Earlier quoted context omitted.
Yeah? Ncurses still a thing? I only ask because that's the only api name I remember from forever ago. I worked on a mud on linux right after high school for awhile. Spent most of the time on the school's bsdi server prior to that though. Then I went java, and as they got less permissive and .net got more permissive I switched at some point. I've really loved the direction C# has gone merging in functional programming…
The only thing that has become "less permissive" is Oracle's proprietary OpenJDK build, which isn't really needed or recommended in 99.9% of cases (except for when the vendor of your proprietary application requires it to provide support). The rest of the ecosystem is "more permissive" than .NET since there are far more FOSS libraries for every task under the sun (which don't routinely go commercial without warnings)…
Re: What .NET 10 GC changes mean for developers
#73I 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?
We first built a proof of concept with 15 basic tasks to implement in both MAUI and Flutter. Things like authentication, navigation, API calls, localization, lists, map, etc. In MAUI, everything felt heavier than it should've been. Tooling issues, overkill patterns, outdated docs, and a lot of small frustrations that added up. In Flutter, we got the same features done much faster and everything just worked. The whole experience was just nicer. The documentation, the community, the developer experience... everything is better.
I love C#, that's what we use for our backend, but for mobile developement Flutter was the clear winner. We launched the new app a year ago and couldn't be happier with our decision.
Re: What .NET 10 GC changes mean for developers
#74Earlier 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…
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 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 decisions to reduce verbosity for 90% of the team for 90% of the use cases because otherwise, there's a lot of repetitive boilerplate.
The use of attributes, reflection, and source generation make the code more "templatized" (true both in our Nest.js codebase as well as the new C# codebase) 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.
Having the option to dip into source generation, for example, is really powerful in allowing the team to reduce boilerplate.
[0] We are hiring, BTW! Seeking experienced C# engineers; very, very competitive comp and all greenfield work with modern C# in a mixed Linux and macOS environment.
Re: What .NET 10 GC changes mean for developers
#75Very mixed feelings about this as there’s a strong case for the decisions made here but it also moves .NET further away from WASMGC, which makes using it in the client a complete non-starter for whole categories of web apps. It’s a missed opportunity and I can’t help but feel that if the .NET team had gotten more involved in the proposals early on then C# in the browser could have been much more viable.
Re: What .NET 10 GC changes mean for developers
#76Earlier 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…
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…
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 that in the age of LLM and AI generated applications, discussing programming languages explicitness is kind of irrelevant.
Re: What .NET 10 GC changes mean for developers
#77Earlier 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).
Re: What .NET 10 GC changes mean for developers
#78Earlier quoted context omitted.
Don't mix mainstream adoption at the same level as regular JavaScrip and Typescript, with availability. Microsoft would wish Blazor would take off like React and Angular, in reality it is seldom used outside .NET shops intranets in a way similar to WebForms.
> Blazor is seldom used outside .NET shops intranets So, in other words, widely used in lots and lots of deployments.
Re: What .NET 10 GC changes mean for developers
#79Earlier quoted context omitted.
A float[] is packed and not a list of pointers in the jvm. An ArrayList is a list of pointers though.
Arrays have a static fixed size though, making them far less useful in practice. Anything one builds with generics is boxed. Dotnet doesn't have this problem.
Eventually value classes might close the gap, finally available as EA.
Re: What .NET 10 GC changes mean for developers
#80Earlier 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).