5 ms·

How does it compare with Kotlin for backend development, which inherits all of the JVM ecosystem?

caspper69 2y ago
There's a lot of banter as to which JIT environment is more performant. As a big C# proponent, my gut tells me the JVM probably has the edge here, but it's not a clean sweep. The CLR has areas where it excels. I would also freely admit that the Java ecosystem is far larger and more mature. The NuGet ecosystem is no slouch, however. But if I were a gambling man, I would bet that AOT compilation will become much more widespread in the .NET ecosystem while Oracle will ensure that you have to pay the piper for GraalVM to do anything interesting. Call it a hunch.
- lordofgibbons 2y ago
  Thanks for the response. I mean from a productivity point of view when building real-world applications. For example, in Go, the development productivity is great, but I'm not so sure about feature development velocity. There are a ton of HTTP libraries, but it's a barren wasteland when it comes to Auth solutions and you have to rely on a separate service which unnecessarily complicates the infrastructure. Need to quickly put together an application that supports enterprise OAuth? tough luck
  - caspper69 2y ago
    Asp.Net supports both internal & external auth(n|z) providers. I have to admit that I haven't done much with the interweb side. Truth be told, the few times I've used Asp.Net, I used KeyCloak as the authentication provider, and that's Java-based, lol. That being said (and damn you for making me link to ms docs yet another time today), there is a built in provider, but my recollection is it did not support OAuth2 or JWT: https://learn.microsoft.com/en-us/aspnet/core/security/?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/security/?view... It may not suit your needs, but maybe that high-level doc can help you drill down quickly and not waste too much time on it. I will say that I do always find it amazing how large sites can be sucessfully operated without too much fuss on the platform. Stack Overflow was notorious for being a very high traffic site that ran on a small cluster of machines and was all done in Asp.Net (might have been the old Windows framework, however). I would like to add that I've been working with Entity Framework (EFCore) for the past year, and I've found it to provide velocity on that front. Never was a big ORM fan, but I can definitely see the use cases now.
  - cyberax 2y ago
    > Need to quickly put together an application that supports enterprise OAuth? ???? That's super easy. I added support for Clerk's OAuth to our app in literally 10 minutes. It was as easy as: > token, err := jwt.ParseString(sessionToken, jwt.WithKeySet(r.keySet), jwt.WithAudience(r.audience)) JWT is from `github.com/lestrrat-go/jwx` I'm not sure about SAML, but at this point it's probably best to not even touch it.
    - lordofgibbons 2y ago
      I'm complaining about having to use external services to do auth, and your solution is to use external services lol
      - deleted 2y ago
        [deleted]
      - cyberax 2y ago
        You can do Google/Microsoft/Apple OAuth is pretty much the same amount of code. E.g.: https://github.com/pgrok/pgrok/blob/dda32d9accfb46ab41f59cae2dce96346435a213/pgrokd/cli/web_server.go#L159 https://github.com/pgrok/pgrok/blob/dda32d9accfb46ab41f59cae... What else do you need?
- neonsunset 2y ago
  OpenJDK used to offer a better baseline performance, particularly at very abstraction-heavy enterprise code. .NET has closed the gap with it since then. Nowadays, .NET can also have quite a Go-like memory profile, especially if you use NativeAOT, but has much higher GC throughput which offers a more foolproof set of tradeoffs. Go has a nice specialized GC design but you cannot tune it at all, and it is centered around moderate allocation rates and consistent latency with small memory footprint. The moment you step outside its boundaries it has problematic regressions .NET's GC implementation is robust against. Java GC implementations are even stronger, but Java also has much higher allocation traffic which offsets some of them. Where .NET shines is by providing a performance ceiling completely unmatched by neither Java nor Go nor any other GC-based language. Performance ceiling in .NET sits every so slightly below Rust and C, in often an indistinguishable way. It is a very nice experience to write systems code in. It won't give you the same safety for writing concurrent code Rust does, but it is so much more productive than dealing with C or C++, especially when it comes to portable builds and tooling. Of course, it supports only a tiny fraction of platforms compared to C. But your target is more likely to be a server or a consumer device or a comparatively beefy Raspberry PI, and .NET works really well on all of those.
  - Capricorn2481 2y ago
    > Where .NET shines is by providing a performance ceiling completely unmatched by neither Java nor Go nor any other GC-based language How does it do this, exactly? What does .NET have that is better than Java for performant code?
    - neonsunset 2y ago
      > What does .NET have that is better than Java for performant code? CIL bytecode, besides what JVM bytecode exposes, provides much lower level access. As a result, C# and Java are languages of different categories and weight classes completely as of 2025. C# is a proper systems programming language in all the ways Java is not. JVM bytecode is also a more difficult to optimize target because all calls are virtual by default and type information is erased. OpenJDK HotSpot has to perform a lot of work just to get to the baseline where CIL starts at, where you have to explicitly make a call virtual and where type information propagates through generic type arguments. OpenJDK used to have a much more powerful compiler but .NET has closed the gap in almost every area, and in other it has surpassed it, or will surpass in the upcoming release(s). It also has a world of optimizations for structs and struct generics which are monomorphized like in Rust, something OpenJDK might only get to in the future. As I said in my previous comment, performance ceiling of .NET is at approximately the level of C/C++/Rust/Zig. Somewhat lower due to compiler limitations but the gap is small enough for it to be easily competitive. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is a good demonstration of performance difference in optimized code in these two languages (note that on <1s execution time benchmarks the startup impact also works against both, so you could look at the comparison between C# AOT and Go to get another picture)
cyberax 2y ago
I still prefer Go, for its first-class lightweight threads. They make _everything_ so much better to debug, compared to async/await that is available in C# and Kotlin. That being said, Java has recently released Project Loom, but it's poorly integrated and often causes subtle issues. It'll require a couple more years to mature. C# doesn't have anything like this for now.
- neonsunset 2y ago
  Go is worse at _lightweight_ concurrency because each Goroutine is much costlier than each .NET task. Also Go has less pleasant concurrency semantics comparatively speaking because Goroutines cannot yield a value - you have to spawn a channel on top of spawning a Goroutine or you need to use a wait group or similar. .NET offers better experience for concurrency-centric code at a much lower overhead for code that has light of finely grained concurrent operations. https://hez2010.github.io/async-runtimes-benchmarks-2024/take2.html https://hez2010.github.io/async-runtimes-benchmarks-2024/tak...
  - cyberax 2y ago
    A million tasks results in 2.5G memory spent (for stacks). This overhead is indeed real, but it is basically immaterial. If you're using that many goroutines, you are going to be CPU-bound unless it's a very special type of workload like a WebSocket dispatcher. In return, you get _normal_ stack traces, and a normal debugging experience. Not a callback hell of async/await. Also no "colored functions" nonsense. Coroutines make sense only for something small and trivial, like the classic tree iterator. And Go now has that: https://go.dev/blog/range-functions https://go.dev/blog/range-functions
    - neonsunset 2y ago
      > In return, you get _normal_ stack traces, and a normal debugging experience. Whatever language you have in mind, it isn't C#. Because all those work perfectly fine there. Please also do a cursory read of what coroutines (stackful vs stackless) in the context of concurrency are. And in Go, all functions are colored, often in ambiguous way due to poor culture of not passing the context where it matters, and goroutines panicking in dependencies that cause uncatchable application crashes. Never change, Go community.
orthoxerox 2y ago
They are very close. The biggest issue with Kotlin is that it has to keep up with Java language changes. It used to be a "strictly better Java", promising zero-friction migrations, but whenever Java adds a new language feature Kotlin has to accommodate it or it will no longer be able to "inherit all of the JVM ecosystem". It's the same with F#. F# used to be ahead of C#, but now every time there's a new C# language feature it's F# that has to adjust or deal with friction in some other way. Discriminated unions are the next big thing that will require F# to put up with C#.

There's a lot of banter as to which JIT environment is more performant. As a big C# proponent, my gut tells me the JVM probably has the edge here, but it's not a clean sweep. The CLR has areas where it excels. I would also freely admit that the Java ecosystem is far larger and more mature. The NuGet ecosystem is no slouch, however. But if I were a gambling man, I would bet that AOT compilation will become much more widespread in the .NET ecosystem while Oracle will ensure that you have to pay the piper for GraalVM to do anything interesting. Call it a hunch.

lordofgibbons 2y ago
Thanks for the response. I mean from a productivity point of view when building real-world applications. For example, in Go, the development productivity is great, but I'm not so sure about feature development velocity. There are a ton of HTTP libraries, but it's a barren wasteland when it comes to Auth solutions and you have to rely on a separate service which unnecessarily complicates the infrastructure. Need to quickly put together an application that supports enterprise OAuth? tough luck
- caspper69 2y ago
  Asp.Net supports both internal & external auth(n|z) providers. I have to admit that I haven't done much with the interweb side. Truth be told, the few times I've used Asp.Net, I used KeyCloak as the authentication provider, and that's Java-based, lol. That being said (and damn you for making me link to ms docs yet another time today), there is a built in provider, but my recollection is it did not support OAuth2 or JWT: https://learn.microsoft.com/en-us/aspnet/core/security/?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/security/?view... It may not suit your needs, but maybe that high-level doc can help you drill down quickly and not waste too much time on it. I will say that I do always find it amazing how large sites can be sucessfully operated without too much fuss on the platform. Stack Overflow was notorious for being a very high traffic site that ran on a small cluster of machines and was all done in Asp.Net (might have been the old Windows framework, however). I would like to add that I've been working with Entity Framework (EFCore) for the past year, and I've found it to provide velocity on that front. Never was a big ORM fan, but I can definitely see the use cases now.
- cyberax 2y ago
  > Need to quickly put together an application that supports enterprise OAuth? ???? That's super easy. I added support for Clerk's OAuth to our app in literally 10 minutes. It was as easy as: > token, err := jwt.ParseString(sessionToken, jwt.WithKeySet(r.keySet), jwt.WithAudience(r.audience)) JWT is from `github.com/lestrrat-go/jwx` I'm not sure about SAML, but at this point it's probably best to not even touch it.
  - lordofgibbons 2y ago
    I'm complaining about having to use external services to do auth, and your solution is to use external services lol
    - deleted 2y ago
      [deleted]
    - cyberax 2y ago
      You can do Google/Microsoft/Apple OAuth is pretty much the same amount of code. E.g.: https://github.com/pgrok/pgrok/blob/dda32d9accfb46ab41f59cae2dce96346435a213/pgrokd/cli/web_server.go#L159 https://github.com/pgrok/pgrok/blob/dda32d9accfb46ab41f59cae... What else do you need?
neonsunset 2y ago
OpenJDK used to offer a better baseline performance, particularly at very abstraction-heavy enterprise code. .NET has closed the gap with it since then. Nowadays, .NET can also have quite a Go-like memory profile, especially if you use NativeAOT, but has much higher GC throughput which offers a more foolproof set of tradeoffs. Go has a nice specialized GC design but you cannot tune it at all, and it is centered around moderate allocation rates and consistent latency with small memory footprint. The moment you step outside its boundaries it has problematic regressions .NET's GC implementation is robust against. Java GC implementations are even stronger, but Java also has much higher allocation traffic which offsets some of them. Where .NET shines is by providing a performance ceiling completely unmatched by neither Java nor Go nor any other GC-based language. Performance ceiling in .NET sits every so slightly below Rust and C, in often an indistinguishable way. It is a very nice experience to write systems code in. It won't give you the same safety for writing concurrent code Rust does, but it is so much more productive than dealing with C or C++, especially when it comes to portable builds and tooling. Of course, it supports only a tiny fraction of platforms compared to C. But your target is more likely to be a server or a consumer device or a comparatively beefy Raspberry PI, and .NET works really well on all of those.
- Capricorn2481 2y ago
  > Where .NET shines is by providing a performance ceiling completely unmatched by neither Java nor Go nor any other GC-based language How does it do this, exactly? What does .NET have that is better than Java for performant code?
  - neonsunset 2y ago
    > What does .NET have that is better than Java for performant code? CIL bytecode, besides what JVM bytecode exposes, provides much lower level access. As a result, C# and Java are languages of different categories and weight classes completely as of 2025. C# is a proper systems programming language in all the ways Java is not. JVM bytecode is also a more difficult to optimize target because all calls are virtual by default and type information is erased. OpenJDK HotSpot has to perform a lot of work just to get to the baseline where CIL starts at, where you have to explicitly make a call virtual and where type information propagates through generic type arguments. OpenJDK used to have a much more powerful compiler but .NET has closed the gap in almost every area, and in other it has surpassed it, or will surpass in the upcoming release(s). It also has a world of optimizations for structs and struct generics which are monomorphized like in Rust, something OpenJDK might only get to in the future. As I said in my previous comment, performance ceiling of .NET is at approximately the level of C/C++/Rust/Zig. Somewhat lower due to compiler limitations but the gap is small enough for it to be easily competitive. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is a good demonstration of performance difference in optimized code in these two languages (note that on <1s execution time benchmarks the startup impact also works against both, so you could look at the comparison between C# AOT and Go to get another picture)

cyberax 2y ago

I still prefer Go, for its first-class lightweight threads. They make _everything_ so much better to debug, compared to async/await that is available in C# and Kotlin. That being said, Java has recently released Project Loom, but it's poorly integrated and often causes subtle issues. It'll require a couple more years to mature. C# doesn't have anything like this for now.

neonsunset 2y ago
Go is worse at _lightweight_ concurrency because each Goroutine is much costlier than each .NET task. Also Go has less pleasant concurrency semantics comparatively speaking because Goroutines cannot yield a value - you have to spawn a channel on top of spawning a Goroutine or you need to use a wait group or similar. .NET offers better experience for concurrency-centric code at a much lower overhead for code that has light of finely grained concurrent operations. https://hez2010.github.io/async-runtimes-benchmarks-2024/take2.html https://hez2010.github.io/async-runtimes-benchmarks-2024/tak...
- cyberax 2y ago
  A million tasks results in 2.5G memory spent (for stacks). This overhead is indeed real, but it is basically immaterial. If you're using that many goroutines, you are going to be CPU-bound unless it's a very special type of workload like a WebSocket dispatcher. In return, you get _normal_ stack traces, and a normal debugging experience. Not a callback hell of async/await. Also no "colored functions" nonsense. Coroutines make sense only for something small and trivial, like the classic tree iterator. And Go now has that: https://go.dev/blog/range-functions https://go.dev/blog/range-functions
  - neonsunset 2y ago
    > In return, you get _normal_ stack traces, and a normal debugging experience. Whatever language you have in mind, it isn't C#. Because all those work perfectly fine there. Please also do a cursory read of what coroutines (stackful vs stackless) in the context of concurrency are. And in Go, all functions are colored, often in ambiguous way due to poor culture of not passing the context where it matters, and goroutines panicking in dependencies that cause uncatchable application crashes. Never change, Go community.

orthoxerox 2y ago

They are very close. The biggest issue with Kotlin is that it has to keep up with Java language changes. It used to be a "strictly better Java", promising zero-friction migrations, but whenever Java adds a new language feature Kotlin has to accommodate it or it will no longer be able to "inherit all of the JVM ecosystem". It's the same with F#. F# used to be ahead of C#, but now every time there's a new C# language feature it's F# that has to adjust or deal with friction in some other way. Discriminated unions are the next big thing that will require F# to put up with C#.