I wonder if this makes .net competitive for high frequency trading...
Why would you ever pick a language like this for HFT? It seems like a nonstarter for me but I guess Java is out there in use
What .NET 10 GC changes mean for developers
101–110 of 253 posts
Re: What .NET 10 GC changes mean for developers
#102I 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?
I don't really understand why Microsoft didn't do a Tauri like thing for C# devs instead of this Maui stuff. It would be a tiny project in comparison and then isn't completely going against the grain like Maui is. If you want a write once / run in more places compromise, the browser already does that very well.
Re: What .NET 10 GC changes mean for developers
#103I 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?
MAUI Blazor Hybrid is great if you won't want to learn XAML. Apple killed Silverlight, Microsoft kept it running for ~20 years. If you stayed close to what Xamarin was the migration to MAUI isn't bad from what I've seen.
Re: What .NET 10 GC changes mean for developers
#104I 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 get culled, in a single stroke… so bundle them and keep them bundled. And now they started using it, to at least detect objects that do not escape lambdas. So its all stack, no more GC involved at all. Its almost at the static allocation thing we do for games. If the model proofs that every hotloop 5 objects are allocated and life until a external event occurs- static allocation and its done.
Great start. But you could do so much more than that with this. If you write a custom JIT whose goal is not just to detect and bytecompile hotloops, but to build a complete multi-lifetime model of object generation.
Re: What .NET 10 GC changes mean for developers
#105Earlier quoted context omitted.
Lmao, functional programming is far from ergonomic
F# is hardly modern functional programming. It's more like a better python with types. And that's much more ergonomic than C#.
It's so weird to describe F# as "Python with Types." First of all, Python is Python with Types. And C# is much more similar to Python than F# is.
Re: What .NET 10 GC changes mean for developers
#106Earlier 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.
I haven't experienced a DI 'nightmare' myself yet, but then again, we have integration tests to cover for that.
Re: What .NET 10 GC changes mean for developers
#107Earlier quoted context omitted.
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…
The trade offs are though that patterns and behind the scenes source code generation is another layer that the devs who have to follow need to deal with when debugging and understanding why something isn’t working. They either spend more time understanding the bespoke things or are bottle necked relying on a team or person to help them get through those moments. It’s a trade off and one that has bit me and others bef…
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.
Re: What .NET 10 GC changes mean for developers
#108Earlier 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…
People were so afraid of macros they ended up with something even worse.
At least with macros I don't need to consider the whole of the codebase and every library when determining what is happening. Instead I can just... Go to the macro.
Re: What .NET 10 GC changes mean for developers
#109Earlier quoted context omitted.
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…
People were so afraid of macros they ended up with something even worse. At least with macros I don't need to consider the whole of the codebase and every library when determining what is happening. Instead I can just... Go to the macro.
C# source generators are...just macros?
Re: What .NET 10 GC changes mean for developers
#110Earlier 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.
If the argument is that most developers can't understand what a DI system does, I don't know if I buy that. Or is the argument it's hard to track down dependencies? Because if that's the case the idiomatic c# has the dependencies declared right in the ctor.