6 ms·

> It's fully-cross platform To a point. Making cross platform native desktop apps is still in the hands of 3rd party vendors such as Avalonia and Uno. MAUI was

> It's fully-cross platform To a point. Making cross platform native desktop apps is still in the hands of 3rd party vendors such as Avalonia and Uno. MAUI was supposed to fix that oversight to a less than stellar results.

rahkiin 2y ago
That is like saying C is not cross platform because there is not a library for making desktop apps that use native components on all those platforms.
- kuschku 2y ago
  .NET/C#'s competitor JVM/Kotlin does provide a UI framework (Jetbrains Compose) that runs on iOS, Android, Windows, Mac, Linux, and the web. That's what you have to compare against, and .NET/C# falls flat.
  - notpushkin 2y ago
    Jetbrains is a third party vendor here, too.
    - kuschku 2y ago
      A third party vendor for the Kotlin language? Kotlin has replaced Java as C#'s largest competitor, so that's what we should be comparing against.
      - toyg 2y ago
        > Kotlin has replaced Java as C#'s largest competitor Er, I don't think this assertion is backed by data. See for example https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html Is Kotlin the most "active", "hot", or "up-and-coming" competitor? Possibly. But the "largest"? Its deployed footprint and popularity are nowhere close to Java's at this point in time.
  - pjc50 2y ago
    That's also not part of the JVM or the Java language.
  - neonsunset 2y ago
    No and it's not even close. Kotlin only has a single Jetbrains Compose (I presume Kotlin Multiplatform is the same thing). It is also subject to the quirks and specifics of JVM implementations, build-systems and package management. Kotlin native partially bypasses this, but its performance is a factor of 0.1-0.01x vs OpenJDK (if there is new data - please let me know). This is very unlike NativeAOT which is on average within 90% of CoreCLR JIT but is also a performance improvement in variety of scenarios. C# and F# get to enjoy the integration that is "much closer to the metal" as well as much richer cross-platform GUI frameworks ecosystem with longer history.
    - kuschku 2y ago
      Which rich cross-platform GUI frameworks are you talking about? Win32? Silverlight/Blend? XAML? MAUI? They're all windows only. Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms. I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option. Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time. While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform. > subject to the quirks and specifics of JVM implementations, build-systems and package management That's a massive advantage over the arcane package management and build systems of .NET Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem. I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
      - neonsunset 2y ago
        There are more than 10 sibling and gp comments that exhaustively address the GUI and other questions :) > That's a massive advantage over the arcane package management and build systems of .NET. Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem. I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet. If you want to sell me on "advantages" of invoking Gradle or Maven over dotnet new web dotnet run curl localhost:port or dotnet new console --aot echo 'Console.WriteLine($"Right now is {DateTime.Now}");' > Program.cs dotnet publish -o {here goes the executable} or dotnet add package {my favourite package} I suppose you would actually need 12 years of improvements given how slow if ever these things get resolved in Java land. Also, what's up with Oracle suing companies for using incorrect JDK distribution that happens to come with hidden license strings attached?
- pantalaimon 2y ago
  back when .NET was first launched it was advertised as the new way of making desktop applications on Windows. Visual C# made it very easy to design GUI interfaces. So this "it's all for backend now" notion is surprising.
  - lelanthran 2y ago
    Same with java - designed for embedded set top devices, pivoted to backend services.
  - toyg 2y ago
    .Net is "Microsoft Java". Like Java it was designed to do everything, but as desktop development died (and mobile development was locked down by Apple and Google, limiting it to their corporate languages), it pivoted towards networked applications.
    - chgs 2y ago
      Visual J++ was Microsoft’s Java
      - toyg 2y ago
        They were legally forbidden from going the Embrace-Extend-Extinguish route there, so they had to build their own version from scratch. C# exists because J++ couldn't.
- quietbritishjim 2y ago
  If there were an old version of C that only worked on one platform but had a graphical toolkit in its standard library, and a new version of C that is cross platform but that graphical toolkit is now ambiguously still sort-of part of the standard library but still not cross platform (and there was no realistic alternative)... Then yes it would be valid to object C is not really cross platform.

rahkiin 2y ago

That is like saying C is not cross platform because there is not a library for making desktop apps that use native components on all those platforms.

kuschku 2y ago
.NET/C#'s competitor JVM/Kotlin does provide a UI framework (Jetbrains Compose) that runs on iOS, Android, Windows, Mac, Linux, and the web. That's what you have to compare against, and .NET/C# falls flat.
- notpushkin 2y ago
  Jetbrains is a third party vendor here, too.
  - kuschku 2y ago
    A third party vendor for the Kotlin language? Kotlin has replaced Java as C#'s largest competitor, so that's what we should be comparing against.
    - toyg 2y ago
      > Kotlin has replaced Java as C#'s largest competitor Er, I don't think this assertion is backed by data. See for example https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html Is Kotlin the most "active", "hot", or "up-and-coming" competitor? Possibly. But the "largest"? Its deployed footprint and popularity are nowhere close to Java's at this point in time.
- pjc50 2y ago
  That's also not part of the JVM or the Java language.
- neonsunset 2y ago
  No and it's not even close. Kotlin only has a single Jetbrains Compose (I presume Kotlin Multiplatform is the same thing). It is also subject to the quirks and specifics of JVM implementations, build-systems and package management. Kotlin native partially bypasses this, but its performance is a factor of 0.1-0.01x vs OpenJDK (if there is new data - please let me know). This is very unlike NativeAOT which is on average within 90% of CoreCLR JIT but is also a performance improvement in variety of scenarios. C# and F# get to enjoy the integration that is "much closer to the metal" as well as much richer cross-platform GUI frameworks ecosystem with longer history.
  - kuschku 2y ago
    Which rich cross-platform GUI frameworks are you talking about? Win32? Silverlight/Blend? XAML? MAUI? They're all windows only. Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms. I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option. Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time. While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform. > subject to the quirks and specifics of JVM implementations, build-systems and package management That's a massive advantage over the arcane package management and build systems of .NET Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem. I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
    - neonsunset 2y ago
      There are more than 10 sibling and gp comments that exhaustively address the GUI and other questions :) > That's a massive advantage over the arcane package management and build systems of .NET. Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem. I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet. If you want to sell me on "advantages" of invoking Gradle or Maven over dotnet new web dotnet run curl localhost:port or dotnet new console --aot echo 'Console.WriteLine($"Right now is {DateTime.Now}");' > Program.cs dotnet publish -o {here goes the executable} or dotnet add package {my favourite package} I suppose you would actually need 12 years of improvements given how slow if ever these things get resolved in Java land. Also, what's up with Oracle suing companies for using incorrect JDK distribution that happens to come with hidden license strings attached?
pantalaimon 2y ago
back when .NET was first launched it was advertised as the new way of making desktop applications on Windows. Visual C# made it very easy to design GUI interfaces. So this "it's all for backend now" notion is surprising.
- lelanthran 2y ago
  Same with java - designed for embedded set top devices, pivoted to backend services.
- toyg 2y ago
  .Net is "Microsoft Java". Like Java it was designed to do everything, but as desktop development died (and mobile development was locked down by Apple and Google, limiting it to their corporate languages), it pivoted towards networked applications.
  - chgs 2y ago
    Visual J++ was Microsoft’s Java
    - toyg 2y ago
      They were legally forbidden from going the Embrace-Extend-Extinguish route there, so they had to build their own version from scratch. C# exists because J++ couldn't.
quietbritishjim 2y ago
If there were an old version of C that only worked on one platform but had a graphical toolkit in its standard library, and a new version of C that is cross platform but that graphical toolkit is now ambiguously still sort-of part of the standard library but still not cross platform (and there was no realistic alternative)... Then yes it would be valid to object C is not really cross platform.