4 ms·

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 .n

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...

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...