Pretty cool and interesting that a big linux vendor is on board with .net.
Pretty cool and interesting that a big linux vendor is on board with .net.
That being said, I've used .Net and C# for over a decade and it's frankly just a clunky language and toolset. It's gotten better with Core (now just.Net), but it's still just not there. It's not a secret that we've been doing more and more TypeScript where I work, but I recently did a little bit of Go and Gorm made EntityFramework feel like something from the stoneage.
So I'm not sure I'd really recommend it unless you already do a lot of .Net. It's not that it's bad, it's just that it's a dated way to build things in a world where the Java way of doing things makes less and less sense.
It obviously lacks a lot of the wider .Net features, like having easy access to ODATA for all your models.
Once I disable Entity Framework object cache globaly (AsNoTracking), it becomes close to the ideal db toolkit for me.
I see a lot of strings in Gorm docs. Those are probably not checked during compilation. This alone differentiates Gorm and EF quite a bit. https://gorm.io/docs/create.html
I am not a vs/c#/.net dev but I tried it once on a windows machine and thought it integrated well and seemed to be a really nice DX. Probably the nicest DX for an "enterprise" stack.
Not wanting to get in a debate on whether you should use an ORM, but I just don't see anything really special about Gorm that makes the other frameworks "ancient".
When I look at this page: https://gorm.io/docs/advanced_query.html I see the same exact crap that makes me wary of JPA Criteria API.
[0]: https://github.com/bflattened/bflat
Other than that, it is smooth and in many advanced scenarios Linux has better support than macOS, unfortunately (still decent, just has quirks).
Also, check out Native AOT in the upcoming .NET 7 because it is really nice for building small and lightweight CLI utilities in .NET and just shipping them to users like you would if they were written in C++ or Rust.