StackOverflow survey (self reported) for 2024 shows it at #5 leaving out HTML/CSS, and SQL[0]
DevJobsScanner shows it at #4 via scraping job postings[1]
It definitely has heavy adoption; well above Rust and Go despite what we see here on HN.
> Does it have any actual advantages over Java?
C# switch expressions with pattern matching (not switch-case), for example[2], are fantastic.
[0] https://survey.stackoverflow.co/2024/technology
[1] https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
[2] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
For a quick comparison, check out https://typescript-is-like-csharp.chrlschn.dev/
Its also popular in Game dev mostly due to Unity, but you have other good options to use C# in game dev as well. I can't think of another kind of software company that uses it a lot other than ones that integrate deeply into the microsoft stack.
As a language, it was far, far ahead of Java for many years (the long dark tea-time of Java 7).
AOT is pretty good when it works.
Sure. For me the best thing about dotnet is that you most likely find an official solution to most "basic" things needed to develop microservices (I intentionally call these basic because you don't want to worry about lots of things at this level). Go on the other hand excels at cross-cut and platform development.
Probably not. Why learn C# if you already know Java? Similarly, why learn Java if you already know C#?
It is also generally less nice to work with - Maven and Gradle are a way bigger PITA than .NET CLI (which is similar to Cargo and Go CLI), NuGet and MSBuild. Base C# syntax lends itself to more streamlined expression of business logic (e.g. with pattern matching, tuples, records and their deconstruction).
In Java, there are odd issues and resulting method gymnastics caused by generics with type erasure, and many of its base containers don't unify nicely as the ones in C# do to IEnumerable<T> or Span<T>.
Writing highly concurrent + parallelized code is way more cumbersome (and generally less efficient) with the current rendition of virtual threads, completable futures or even upcoming structured concurrency API than doing so with .NET 'Task<T>'s and their composition.
ASP.NET Core is much faster and more focused than Spring Boot. EF Core is way more powerful and significantly terser to use than Hibernate, JPA or, to an extent, JOOQ.
You can also relatively easily ship fully self-contained and relatively compact (with trimming) applications, often as a single file. With additional effort, NativeAOT provides native compilation and smaller-than-Go binaries while having much wider support across ecosystem than GraalVM Native Image within JVM space (e.g. it's one command away to get a gRPC-based ASP.NET Core microservice template which compiles to fully native binary, it also does not use any special tricks - just regular code).
They are very much not 1:1 languages. Depending on the domain, there may very large differences in developer productivity, level of comfort and effort required to achieve a competitive implementation.
Java strengths lie in its comparatively larger and more diverse ecosystem in enterprise space alongside certain high-profile projects, predominantly by Apache foundation. On technical merits it does have less to offer.
I'd say if your goal to expand your horizons, then it's more important to pick a problem that can't be nicely solved with Java. In that case, C# will offer more pleasant and moderately familiar experience over C, C++ or, to an extent, Rust (which is another great language to learn).
Yes JVM currently sucks in value types and low level C++ like coding, .NET is great there, but not everyone needs those capabilities, and when they do, most don't shy away of doing some JNI.
On the technical level, .NET doesn't have GraalVM like tooling (it is a whole compiler framework not a plain AOT compiler), the MSR Phoenix project was canceled, Longhorn was canceled so nothing Android like, no real time GCs and bare metal deployments like PTC, Aicas and microEJ, no VMs for M2M, copiers, telephone switches.
In what concerns EF, I keep my point of view that I rather use Dapper with SP.
I definitely liked writing Kotlin code in the past, but we had a medium sized Kotlin web api at a previous job, and a very large c++ app. The c++ app was quicker to compile than the Kotlin app on many many occasions, and the toolchain and IDE integration situation reminded me (not in a good way) of working with eclipse - even with intellij
Compile times might be an issue, I know it was an issue in the past.
C++ can actually be quite fast to compile, if the right decisions how to approach the build infrastructure and code styles were taken, which usually is not the case, hence its fame to slowness.
Here's some data of 12M scraped job offerings:
https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
JavaScript: 31.42%
Python: 19.68%
Java: 18.51%
C#: 11.90%
C/C++: 8.29%
Go: 2.38%
Rust: 0.39%
I was a bit shocked about the Rust numbers. I'd expected it to be slightly above Go. Anyway. C# is strong. Java even more.
Also, "job openings" is not the same as jobs, my organization isn't currently hiring engineering roles, yet we employ ~60 engineers, of whom most write Rust. And we're just a tiny startup.
Why's that?
Go was designed explicitly to serve the particular needs of a particular area of software development that allegedly sees more than average development activity. In fact, its designers have expressed some surprise that people found it useful in other areas of programming. Rust, on the other hand, tries to be much more general purpose. Being a jack of all trades master of none, so to speak, is a great technical quality, but without particular focus it is much harder to get the numbers up.
It is quite similar to why Javascript blows all of the other languages out of the water. It would be surprising if Rust had more usage like it would be surprising if C had more usage than Javascript.