4 ms·

Yeah. I’ve been trained to aspnetcore in my previous job. Saying I wasn’t hyped is an understatement. Then I had to work with it for more than a year. I discov

by pjerem 2y ago

Yeah. I’ve been trained to aspnetcore in my previous job. Saying I wasn’t hyped is an understatement. Then I had to work with it for more than a year. I discovered two things : - 1 ) I was wrong : it’s a very good and really well designed framework. I have a huge respect for the engineers behind it. It’s easy to work on all the layers you need. It’s also easy to ignore every layers you don’t need. - 2) The documentation is awful. And I don’t mean the inline documentation : every method of the framework is very well documented in code. However the online docs, the one which should guide you and make the pieces click together is a real pain to navigate, is poorly written, and that’s when it exists. Fortunately I also discovered that there is a very welcoming community in the ecosystem. Mostly composed of people who discovered at their $job that the tech was indeed cool but that Microsoft is shitty when it comes to be friendly.

radicalbyte 2y ago
I've been using .Net since 2002, as my main framework since 2007 and have always stayed on the edge (as part of alt.net, the part of the community who pushed .net core and basically the entire .net team nowadays). So for the last 6 months I've been using golang. I really like it. Fast, simple, native.... but it's like using tonka toys compared to .net core. It's slower for webservices and everything is just more work. Yes being a wizard with .net and only decently productive in golang is a difference but that's not it. It's just nowhere near as mature as a language or ecosystem.
- neonsunset 2y ago
  And it is moving so much faster in runtime/compiler improvements. Implementation wise, it outdoes the Go at things Go is renown for. The only last, and most critical piece of the puzzle that's missing is laser focus on simplicity of implementation. It is improving, but if you use generic composition and very terse writing style ala Rust traits and impl., pass data by `ref T`, occasionally manually manage the memory, you soon enough have people up in arms about this kind of unorthodox approach in the sphere of line of business applications (even when it tolerates that in other lower-level or just more limited languages, everything has to be abstracted away and very wordy).
  - radicalbyte 2y ago
    Exactly, if I'd have started this project then I would have used .Net. We don't need to support native / cgo. Without that C# is better in every way. I'd like there to be some kind of profile / compiler level support so we can do full manual memory management (stealing from Rust as you say) but also to be easily able to forbid that within our own projects. I don't want my frontend developers doing silly things :-)
    - bob1029 2y ago
      > so we can do full manual memory management C#/.NET supports unsafe mode, which can be configured on a per-csproj basis. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/unsafe-code https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

by pjerem 2y ago

radicalbyte 2y ago

I've been using .Net since 2002, as my main framework since 2007 and have always stayed on the edge (as part of alt.net, the part of the community who pushed .net core and basically the entire .net team nowadays). So for the last 6 months I've been using golang. I really like it. Fast, simple, native.... but it's like using tonka toys compared to .net core. It's slower for webservices and everything is just more work. Yes being a wizard with .net and only decently productive in golang is a difference but that's not it. It's just nowhere near as mature as a language or ecosystem.

neonsunset 2y ago
And it is moving so much faster in runtime/compiler improvements. Implementation wise, it outdoes the Go at things Go is renown for. The only last, and most critical piece of the puzzle that's missing is laser focus on simplicity of implementation. It is improving, but if you use generic composition and very terse writing style ala Rust traits and impl., pass data by `ref T`, occasionally manually manage the memory, you soon enough have people up in arms about this kind of unorthodox approach in the sphere of line of business applications (even when it tolerates that in other lower-level or just more limited languages, everything has to be abstracted away and very wordy).
- radicalbyte 2y ago
  Exactly, if I'd have started this project then I would have used .Net. We don't need to support native / cgo. Without that C# is better in every way. I'd like there to be some kind of profile / compiler level support so we can do full manual memory management (stealing from Rust as you say) but also to be easily able to forbid that within our own projects. I don't want my frontend developers doing silly things :-)
  - bob1029 2y ago
    > so we can do full manual memory management C#/.NET supports unsafe mode, which can be configured on a per-csproj basis. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/unsafe-code https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...