5 ms·

Will this make .NET. a contender for Go in places where .NET is used widely and Go is used to develop standalone tools that are easily distributed?

by AnonC 6y ago

tybit 6y ago
As a .NET fan this is one less thing for me to tempted by Go for. The other large remaining point is start up time for e.g CLIs and AWS Lambdas. .NET Core has been making great progress there but I think a true native executable will always beat it.
- mdasen 6y ago
  What is truly native is debatable. Go has a runtime too. .NET has some AOT compilation to native code now and it has trimming so that it doesn't include things you don't need. Go will likely continue to have a bit of an advantage for short-running processes, but .NET and Java are both likely to start getting into this space. Micronaut is advertising "startup in tens of milliseconds with GraalVM". Microsoft is working on integrating all the Xamarin/Mono/Framework/Core work into one .NET and there's a lot of great stuff there. CoreRT isn't going to be productized, but it's likely that a lot of the ideas will become part of .NET in the future. We've seen announcements about compile-time code generation which will help .NET avoid reflection in AOT-compiled scenarios. Go is very successful for a reason, but Java and .NET aren't ignoring Go's advantages. I think there was a bit of complacency for a while. Java was the open-source statically-typed platform and C# was the Microsoft one. As new languages like Scala, Kotlin, and Go came on the scene, there was renewed interest in pushing Java forward and as Microsoft pivoted away from a Windows-first-and-only state of mind, there were a lot of areas to push C# into (with help from the Mono/Xamarin folk). AOT compilation is going to be important for things like iOS development and WebAssembly which both look like they're going to be big emphases for Microsoft going forward (they've announced how they're going to unify iOS/Android/Windows/Mac development with .NET 6 and Blazor seems like one of the more exciting WASM attempts). Again, not taking anything away from Go, but I think Java and .NET will both be making strides in startup times and AOT compilation.
MarkSweep 6y ago
Given how large Go exes can get, I think with a little work .NET apps can start to compare favorably, at least in terms of size-on-disk.
JamesSwift 6y ago
I actually very recently wrote a project originally as a single binary .net WebAPI, but rewrote it to go because runtime memory usage was comparatively insane. That is likely WebAPI's fault though, so I'm optimistic about sticking with.net in the future for these single-binary scenarios. The thing go has though is that single-binary cross-compilation is _much_ easier to grok. It took a lot of reading .net docs to understand what incantations I needed to pass to the compiler.
- aliswe 6y ago
  Was this on .netcore 2? If yes, then memory usage for moderate apps has gone down significantly. Turns out they just optimized for demanding apps before.
  - JamesSwift 6y ago
    Yes, it was on the latest. I even tried enabling 'desktop' mode for memory, which helped but barely. One of my main goals was to have a single binary hosted on heroku free dyno (512mb ram), and this was using ~1gb vs go which idled at ~50mb.
    - davidfowl 6y ago
      What was the API doing? 1gb with client GC? I’m assuming a single core as well?
      - JamesSwift 6y ago
        Nothing really, it just loaded up a JSON file into memory and then served 2 endpoints to query that structure. I dont have the .net version uploaded, but here is the go version [1]. The 1gb might have been while running load testing on it, I dont remember entirely. It was very consistently hitting it though. [1] - https://github.com/J-Swift/GamesDbMirror-go/blob/master/pkg/server/server.go https://github.com/J-Swift/GamesDbMirror-go/blob/master/pkg/...

Will this make .NET. a contender for Go in places where .NET is used widely and Go is used to develop standalone tools that are easily distributed?

by AnonC 6y ago

Will this make .NET. a contender for Go in places where .NET is used widely and Go is used to develop standalone tools that are easily distributed?

tybit 6y ago

As a .NET fan this is one less thing for me to tempted by Go for. The other large remaining point is start up time for e.g CLIs and AWS Lambdas. .NET Core has been making great progress there but I think a true native executable will always beat it.

mdasen 6y ago
What is truly native is debatable. Go has a runtime too. .NET has some AOT compilation to native code now and it has trimming so that it doesn't include things you don't need. Go will likely continue to have a bit of an advantage for short-running processes, but .NET and Java are both likely to start getting into this space. Micronaut is advertising "startup in tens of milliseconds with GraalVM". Microsoft is working on integrating all the Xamarin/Mono/Framework/Core work into one .NET and there's a lot of great stuff there. CoreRT isn't going to be productized, but it's likely that a lot of the ideas will become part of .NET in the future. We've seen announcements about compile-time code generation which will help .NET avoid reflection in AOT-compiled scenarios. Go is very successful for a reason, but Java and .NET aren't ignoring Go's advantages. I think there was a bit of complacency for a while. Java was the open-source statically-typed platform and C# was the Microsoft one. As new languages like Scala, Kotlin, and Go came on the scene, there was renewed interest in pushing Java forward and as Microsoft pivoted away from a Windows-first-and-only state of mind, there were a lot of areas to push C# into (with help from the Mono/Xamarin folk). AOT compilation is going to be important for things like iOS development and WebAssembly which both look like they're going to be big emphases for Microsoft going forward (they've announced how they're going to unify iOS/Android/Windows/Mac development with .NET 6 and Blazor seems like one of the more exciting WASM attempts). Again, not taking anything away from Go, but I think Java and .NET will both be making strides in startup times and AOT compilation.

MarkSweep 6y ago

Given how large Go exes can get, I think with a little work .NET apps can start to compare favorably, at least in terms of size-on-disk.

JamesSwift 6y ago

I actually very recently wrote a project originally as a single binary .net WebAPI, but rewrote it to go because runtime memory usage was comparatively insane. That is likely WebAPI's fault though, so I'm optimistic about sticking with.net in the future for these single-binary scenarios. The thing go has though is that single-binary cross-compilation is _much_ easier to grok. It took a lot of reading .net docs to understand what incantations I needed to pass to the compiler.

aliswe 6y ago
Was this on .netcore 2? If yes, then memory usage for moderate apps has gone down significantly. Turns out they just optimized for demanding apps before.
- JamesSwift 6y ago
  Yes, it was on the latest. I even tried enabling 'desktop' mode for memory, which helped but barely. One of my main goals was to have a single binary hosted on heroku free dyno (512mb ram), and this was using ~1gb vs go which idled at ~50mb.
  - davidfowl 6y ago
    What was the API doing? 1gb with client GC? I’m assuming a single core as well?
    - JamesSwift 6y ago
      Nothing really, it just loaded up a JSON file into memory and then served 2 endpoints to query that structure. I dont have the .net version uploaded, but here is the go version [1]. The 1gb might have been while running load testing on it, I dont remember entirely. It was very consistently hitting it though. [1] - https://github.com/J-Swift/GamesDbMirror-go/blob/master/pkg/server/server.go https://github.com/J-Swift/GamesDbMirror-go/blob/master/pkg/...