[paulmd]

C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows. You can write architecture astronaut shit in C# just as much as Java.

The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.

[Hawxy]

> C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows.

C#/.NET hasn't been tied to windows for a number of years now. .NET Core/.NET 5 is cross-platform and great to work with. All of our CI/CD runs on Linux agents too.

[erik_seaberg]

The branding has been churned like crazy. As far as I can tell, the first .NET version that officially supported (almost?) the complete API on Linux was released last month, so we’d have to sign up for being an early adopter.

[phillipcarter]

"the complete API" is a bit of a misnomer, since there have been new APIs and runtime capabilities that aren't available to the Windows-only, older runtime (The .NET Framework). This has been the case since at least .NET Core 2.1 but has continued ever since.

There are several APIs in the older runtime that are intentionally not brought forward, and what I believe you're referring to is this announcement: https://github.com/dotnet/announcements/issues/130

The remaining APIs are (mostly) AppDomains, Remoting, Web Forms, WCF server, and Windows Workflow, most of which is either an acknowledged "this was the wrong way to do it so we won't bring it forward" (e.g., Remoting) or tied to Windows anyways (e.g., WCF).

[mythz]

> C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows

C# is not tied to Windows, some new features in the latest C# 9.0 doesn't even support running on the Windows-only classic .NET Framework.

All new .NET development + C# features is being invested into .NET 5+ (FKA .NET Core), i.e. the high-performance cross-platform runtime.

> The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.

Citation needed, I deploy my .NET 5 Apps with Linux tools, either rsync, Docker as well as AWS ECS. All clean + simple, only requires a single command to publish your App ready for distribution, that you can either rsync across or include it in the runtime image of your Docker build.

Tried to publish a Java package last week and the whole experience was a shit show, by far the worst experience of all languages where the recommendation to publish a package is to push it to bintray first, make it available to jCenter than sync it to Maven, where you need to get manual approval to include it in jCenter then you need to create yet another account/credentials with a 3rd Party which requires a manual request via a damn Jira ticket. Then each package manager has different requirements as to what a package needs, I could publish it to bintray but couldn't get it to jCenter without uploading a POM which new Kotlin projects aren't created with, then MavenCentral requires a stricter POM and Java Docs but there's no standard way to publish to a repository as bintray needs their own non-compatible task, so now I have duplicated generated POM's in my gradle build to satisfy different repositories, for bintray I needed to hook into their bintrayUpload task and generate the POM just just before it uploaded the package which I needed to decompile its sources to find out where exactly the POM file needs to be written to, no examples of which existed for Kotlin build.gradle.kts scripts that new Kotlin projects are created with. Then there's the case that every build.gradle example uses configuration that is already deprecated and Java/gradle seems to be the only one requiring uploading binary .jar's with your source projects.

Every other language has a single repository you can publish to that you don't need to jump hoops to get, published using standard tools, simple, clean, straight-forward & well documented.

[pjmlp]

> an interpreted bytecoded high-level language

Something C# never was, given that it always JITs before execution and AOT compilation to dynamic libraries has been available since version 1.0 via NGEN.

Plus lots of additional AOT alternatives like Windows 8.x Bartok compiler, .NET Native and CoreRT.

This on top of third party offerings like Mono AOT or IL2CPP, and the research compilers from Singularity and Midori projects.

Whereas for Java, while AOT has been available since around 2000, it has been for the most part only available on commercial JDKs, and free beer AOT only came with the release of GraalVM community, the addition of J/Rockit JIT caches into OpenJDK, and IBM releasing OpenJ9 as FOSS as well.

[x87678r]

Agreed C# and Java are virtually identical. However the cultuer is completely different. The plethora of libraries to me ends up being a handicap. We have had a bunch of different Java developers on our project and each one does things differently so we end up with a huge mess. I didn't see such problems in C# world where maybe we just had better devs that concentrated on clean models instead of incorporating fashionable libraries and other moving parts.

[sverhagen]

So your team had a problem, that's what I'm reading here mostly.

[manigandham]

Your opinion on C# is outdated by at least 5 years of massive changes in the entire .NET ecosystem.

[optimiz3]

> C# is basically the same thing

Abstracted far enough, everything is basically the same thing.

[albru123]

> C# is not nearly as good in this respect.

How so, I had nothing but issues when trying to deploy cross-platform Java because of the Java ecosystem itself being bad compared to C# or Golang where you just compile stuff and run it.

[pjmlp]

With the right JDK you can do the same with Java as well.