7 ms·

Agreed, much like Java turned out to be the next evolution of Java. Python is the the 'good enough at everything + huge ecosystem' language that you can't repla

by mbb70 3y ago

Agreed, much like Java turned out to be the next evolution of Java. Python is the the 'good enough at everything + huge ecosystem' language that you can't replace no matter how much cooler the concurrency paradigm.

NoboruWataya 3y ago
Definitely agree that Java has come a long way recently and not at all looking to start a language war, but I think that at the very least Java should share its "next evolution of Java" podium with Kotlin.
adgjlsfhk1 3y ago
IMO Java is still at least 5 years behind C#. It's hard for me to take Java seriously without project Valhalla.
- pjmlp 3y ago
  Just like .NET Native AOT is quite some years behind GraalVM, OpenJ9, having high profile real time bare metal runtimes like PTC and Aicas have been selling for 20 years with deployment in battlefield scenarios, being used in the biggest mobile OS platform. As someone working on a polyglot delivery agency, many UNIX shops still don't take .NET seriously, given how many key libraries are still stuck in VS/Windows workflows or not yet ported from .NET Framework. It is more than just Java vs C#, the several JVM implementations and CLR also matter. Note that even Microsoft takes Java seriously enough to have their own Java distribution, after the Sun/Microsoft drama, and any major Azure product deployment also requires day 1 support for Java.
  - oblio 3y ago
    99.99% of companies only use OpenJDK derived JDKs, though.
    - pjmlp 3y ago
      Sure if we forget ART isn't really derived from OpenJDK, and there are plenty of Java implementations beyond 0.01%, in business for the last 30 years.
  - neonsunset 3y ago
    This is unlikely, since Native AOT is not exactly a separate flavour, it builds right on the same compiler optimizations, sans those that are possible with JIT only. In addition, years of development is a bad, bad proxy for the results. .NET had been changing very slowly up until it went the .NET Framework -> .NET Core -> .NET OSS route. Since then, the last 4 years have brought more (performance and feature) changes than the previous 10+. With .NET 8, I highly doubt JVM implementations would have superiority (with Dynamic PGO being enabled by default closing one of the avenues where HotSpot used to have an advantage), except maybe in certain niche scenarios. Also, Java can no longer be compared to C# directly (because they are not equal in features, or even levels of abstractions you can go as of now). A fair comparison would be Kotlin for higher level and Go for lower level scenarios.
    - pjmlp 3y ago
      Except plenty of people, including Microsoft own products, are still stuck in .NET Framework. Additionally plenty of business are only adopting LTS versions. Then we have big names like Sitecore, that decided it was time to move on, and all their major acquisition are based on Java and JS/TS products. The GUI civil war isn't helping the community. The .NET team was grilled on twitter due to the way the last Technetpower benchmark was conducted. While F# keeps being neglected, VB is stable, and CLR changes to mean C# Language Runtime, JVM now enjoys Scala, Kotlin and Clojure. NativeAOT is still not going to be fully done for .NET 8, and apparently it will require minimal APIs to be usable, hello rewrites, yet again. Still no roadmap for GUI support on Native AOT, and then there is the recent joke that VSCode MAUI plugin doesn't do Linux anyway, only Android, when on Linux. It is a bit more complex than playing football teams with languages on the school playground.
      - neonsunset 3y ago
        Let's address these claims one by one: > Except plenty of people, including Microsoft own products, are still stuck in .NET Framework. Would this necessitate evaluation of Java 8's (and corresponding JVM) viability against modern languages and platforms too? > Additionally plenty of business are only adopting LTS versions. .NET 6 is an LTS version and so is 8. > Then we have big names like Sitecore, that decided it was time to move on, and all their major acquisition are based on Java and JS/TS products. When a particular (medium size) company picks a technology, it has no impact on its viability because it does not retroactively alter its advantages or disadvantages unless the company invests in the ecosystem (which Sitecore does not, but then again, this is a nonsensical argument) > The GUI civil war isn't helping the community. It is true that situation with GUI frameworks in C# is far from ideal, it is being worked on, but there is no catching up to JS/TS front-ends written even for desktop applications. For all it's worth, Xamarin continues to be loved by enterprise, and, maybe, one day MAUI will be made successful despite extremely rough start (I'm not holding my breath though). > The .NET team was grilled on twitter due to the way the last Technetpower benchmark was conducted. Almost all top participants in Techempower pretty much do some degree of benchmark gaming. However, this does not, by itself, indicate the deficiency of the language or the runtime (if it did, we'd have all popular languages classified as deficient). In fact, asm emitted for C# trades blows with the likes emitted for C++. In many-core gRPC scenarios, Kotlin is at a similar level of performance, but as a language itself does not allow going as low-level as C# does (it effectively competes with both Go and Kotlin, offering a different set of tradeoffs). > While F# keeps being neglected, VB is stable, and CLR changes to mean C# Language Runtime, JVM now enjoys Scala, Kotlin and Clojure. Can you expand on this? F# ecosystem does see less developer activity than C# from the language standpoint. However, it receives all the same performance and shared library improvements, and .NET does not introduce changes which break F#. Similar to Sitecore statement, VM being targeted by a multitude of languages does not make it automatically better (or worse) nor is a proxy for its performance characteristics. It is necessary to assess a technology at its face value. > NativeAOT is still not going to be fully done for .NET 8, and apparently it will require minimal APIs to be usable, hello rewrites, yet again. NativeAOT was "done" for .NET 7 for win-x64, linux-x64 and linux-arm64 targets, with osx-arm64 (it was not a goal for .NET 7) pull-request narrowly missing the feature snap window, therefore getting postponed to .NET 8. It also appears the argument might stem from conclusions learned from GraalVM AOT which do not apply to .NET. Unless used in a serverless function, back-end .NET deployments are best served by simply staying with JIT, which would offer higher sustained throughput. Native AOT is first and foremost designed for completely different scenarios. > Still no roadmap for GUI support on Native AOT, and then there is the recent joke that VSCode MAUI plugin doesn't do Linux anyway, only Android, when on Linux. All code targeting .NET historically relied on features by definition incompatible with true AOT (like in C++). It is a non-trivial effort to address issues of specific frameworks, which is being done, and the language itself adopts newer features (source generation. unsafe accessors, linker/trimmer improvements) to make it easier. As for Linux, please give Avalonia a try.

by mbb70 3y ago

NoboruWataya 3y ago

Definitely agree that Java has come a long way recently and not at all looking to start a language war, but I think that at the very least Java should share its "next evolution of Java" podium with Kotlin.

adgjlsfhk1 3y ago

IMO Java is still at least 5 years behind C#. It's hard for me to take Java seriously without project Valhalla.

pjmlp 3y ago
Just like .NET Native AOT is quite some years behind GraalVM, OpenJ9, having high profile real time bare metal runtimes like PTC and Aicas have been selling for 20 years with deployment in battlefield scenarios, being used in the biggest mobile OS platform. As someone working on a polyglot delivery agency, many UNIX shops still don't take .NET seriously, given how many key libraries are still stuck in VS/Windows workflows or not yet ported from .NET Framework. It is more than just Java vs C#, the several JVM implementations and CLR also matter. Note that even Microsoft takes Java seriously enough to have their own Java distribution, after the Sun/Microsoft drama, and any major Azure product deployment also requires day 1 support for Java.
- oblio 3y ago
  99.99% of companies only use OpenJDK derived JDKs, though.
  - pjmlp 3y ago
    Sure if we forget ART isn't really derived from OpenJDK, and there are plenty of Java implementations beyond 0.01%, in business for the last 30 years.
- neonsunset 3y ago
  This is unlikely, since Native AOT is not exactly a separate flavour, it builds right on the same compiler optimizations, sans those that are possible with JIT only. In addition, years of development is a bad, bad proxy for the results. .NET had been changing very slowly up until it went the .NET Framework -> .NET Core -> .NET OSS route. Since then, the last 4 years have brought more (performance and feature) changes than the previous 10+. With .NET 8, I highly doubt JVM implementations would have superiority (with Dynamic PGO being enabled by default closing one of the avenues where HotSpot used to have an advantage), except maybe in certain niche scenarios. Also, Java can no longer be compared to C# directly (because they are not equal in features, or even levels of abstractions you can go as of now). A fair comparison would be Kotlin for higher level and Go for lower level scenarios.
  - pjmlp 3y ago
    Except plenty of people, including Microsoft own products, are still stuck in .NET Framework. Additionally plenty of business are only adopting LTS versions. Then we have big names like Sitecore, that decided it was time to move on, and all their major acquisition are based on Java and JS/TS products. The GUI civil war isn't helping the community. The .NET team was grilled on twitter due to the way the last Technetpower benchmark was conducted. While F# keeps being neglected, VB is stable, and CLR changes to mean C# Language Runtime, JVM now enjoys Scala, Kotlin and Clojure. NativeAOT is still not going to be fully done for .NET 8, and apparently it will require minimal APIs to be usable, hello rewrites, yet again. Still no roadmap for GUI support on Native AOT, and then there is the recent joke that VSCode MAUI plugin doesn't do Linux anyway, only Android, when on Linux. It is a bit more complex than playing football teams with languages on the school playground.
    - neonsunset 3y ago
      Let's address these claims one by one: > Except plenty of people, including Microsoft own products, are still stuck in .NET Framework. Would this necessitate evaluation of Java 8's (and corresponding JVM) viability against modern languages and platforms too? > Additionally plenty of business are only adopting LTS versions. .NET 6 is an LTS version and so is 8. > Then we have big names like Sitecore, that decided it was time to move on, and all their major acquisition are based on Java and JS/TS products. When a particular (medium size) company picks a technology, it has no impact on its viability because it does not retroactively alter its advantages or disadvantages unless the company invests in the ecosystem (which Sitecore does not, but then again, this is a nonsensical argument) > The GUI civil war isn't helping the community. It is true that situation with GUI frameworks in C# is far from ideal, it is being worked on, but there is no catching up to JS/TS front-ends written even for desktop applications. For all it's worth, Xamarin continues to be loved by enterprise, and, maybe, one day MAUI will be made successful despite extremely rough start (I'm not holding my breath though). > The .NET team was grilled on twitter due to the way the last Technetpower benchmark was conducted. Almost all top participants in Techempower pretty much do some degree of benchmark gaming. However, this does not, by itself, indicate the deficiency of the language or the runtime (if it did, we'd have all popular languages classified as deficient). In fact, asm emitted for C# trades blows with the likes emitted for C++. In many-core gRPC scenarios, Kotlin is at a similar level of performance, but as a language itself does not allow going as low-level as C# does (it effectively competes with both Go and Kotlin, offering a different set of tradeoffs). > While F# keeps being neglected, VB is stable, and CLR changes to mean C# Language Runtime, JVM now enjoys Scala, Kotlin and Clojure. Can you expand on this? F# ecosystem does see less developer activity than C# from the language standpoint. However, it receives all the same performance and shared library improvements, and .NET does not introduce changes which break F#. Similar to Sitecore statement, VM being targeted by a multitude of languages does not make it automatically better (or worse) nor is a proxy for its performance characteristics. It is necessary to assess a technology at its face value. > NativeAOT is still not going to be fully done for .NET 8, and apparently it will require minimal APIs to be usable, hello rewrites, yet again. NativeAOT was "done" for .NET 7 for win-x64, linux-x64 and linux-arm64 targets, with osx-arm64 (it was not a goal for .NET 7) pull-request narrowly missing the feature snap window, therefore getting postponed to .NET 8. It also appears the argument might stem from conclusions learned from GraalVM AOT which do not apply to .NET. Unless used in a serverless function, back-end .NET deployments are best served by simply staying with JIT, which would offer higher sustained throughput. Native AOT is first and foremost designed for completely different scenarios. > Still no roadmap for GUI support on Native AOT, and then there is the recent joke that VSCode MAUI plugin doesn't do Linux anyway, only Android, when on Linux. All code targeting .NET historically relied on features by definition incompatible with true AOT (like in C++). It is a non-trivial effort to address issues of specific frameworks, which is being done, and the language itself adopts newer features (source generation. unsafe accessors, linker/trimmer improvements) to make it easier. As for Linux, please give Avalonia a try.