The original thread is on the devil’s website and I don’t want to direct traffic to it, so here’s a link to the tweet instead:
https://twitter.com/davidfowl/status/1671351948640129024?s=46&t=OEG0fcSTxko2ppiL47BW1Q
The original thread is on the devil’s website and I don’t want to direct traffic to it, so here’s a link to the tweet instead:
https://twitter.com/davidfowl/status/1671351948640129024?s=46&t=OEG0fcSTxko2ppiL47BW1Q
Dotnet had really been the ecosystem i keep coming back to. It’s been so frictionless. It could be experience, but I really never feel like I’m fighting with it. Running plain C might be the only other ecosystem that I would hold as a less frictionless experience. I genuinely don’t hold any frustrations with it. I don’t have any ideological problems around Microsoft’s involvement. The tool lets me solve problems effectively.
The only thing Im missing is a good llvm target for the clr something like what the kotlin native guys enjoy so i can take the ecosystems to new places.
Sure EFcore can be tiresome and LINQ is inefficiënt. But I’m going to be honest here. If you’re trying to squeeze performance out of an ORM and you’re running up against performance limits of LINQ, maybe not use a time-saving tool as a power tool?
Maybe I’m simping a bit over it, but I’m not seeing alot of positive content about a tool that has only been very productive in my experience. Maybe because all of the dotnet users are too busy solving actual problems for people haha 😂
Oh and newtonsoft… And maybe xUnit and nUnit could make up and figure out a way to be ergonomic AND work well multi-threaded.
Performance limits of LINQ…?
You’re getting nearly the same performance out of loopes generated by LINQ as you would normal for loops.
If you’re referring to LINQ and EF Core, you’re generation SQL with it, not running LINQ. And that query generation is incredibly performant these days (I think EF 7 was something like 5% slower than dapper?).
So luckily you can squeeze a ton of performance out of it!