5 ms·

Java is an inferior language to C#. To get a superior language you would likely have to go for Kotlin. There is no comparison, because Java gets features today

Java is an inferior language to C#. To get a superior language you would likely have to go for Kotlin. There is no comparison, because Java gets features today that C# had for years. Not even mentioning having to retrofit green threads because adopting async/await (used by TS, Rust, Swift and other languages) is impossible at this point.

throy930493 3y ago
C# is a better language, but the JVM is a significantly better ecosystem. Java will always be behind (and type erasure for generics is annoying enough as someone who started in C# that I don't think it will ever catch up) but between hotspot and being the preferred language of 2/3rds of the clouds I think it clearly wins.
- deleted 3y ago
  [deleted]
- anoy8888 3y ago
  If you like jvm, use closure instead.
  - hmottestad 3y ago
    Sorry you’re down voted. Closure might not be what the author is looking for. There are a lot of languages you can use with the JVM, Closure is one of them, Groovy, Scala and Kotlin are some more. Kotlin is gaining a lot of traction, especially since it’s backed by JetBrains.
    - sgt 3y ago
      Clojure*
  - deleted 3y ago
    [deleted]
- bcrosby95 3y ago
  Type erasure is why there's such a rich ecosystem of 3rd party languages that run on the jvm.
  - bmm6o 3y ago
    Meaning that it would be harder for those languages on the clr because of generics? Would typing all generics as Object not be essentially equivalent?
- throwaway2037 3y ago
  type erasure for generics is annoying I too have spent significant time programming in both C# and Java. This complaint about type erasure in Java: When does it affect your daily life? There are so many craft workarounds available now that it hardly comes up anymore. Also, would your opinion of Java significantly change if type erasure was removed or never existed?
  - throy930493 3y ago
    I have much more experience in C# then Java FWIW, so you're welcome to take my opinions with a grain of salt. I've had a couple of really annoying errors with Beam serializers that took me way longer to debug then I thought was worthwhile. I think it is a worse choice, it's too ingrained in the language and ecosystem to change. That and a couple of other nits would likely make me pick Java over C# or Go if I was starting a new project going forward.
ecshafer 3y ago
F# is far superior to C# as a language. If you are going to jump to the .NET runtime that's the tool to go for.
- ZeroClickOk 3y ago
  apples and oranges
thangalin 3y ago
Java, prints 1: Set<File> s = new HashSet<File>(); s.add( new File( "c:/temp" ) ); s.add( new File( "c:/temp" ) ); System.out.println( s.size() ); C#, prints 2: ISet<FileInfo> s = new HashSet<FileInfo>(); s.Add( new FileInfo( "c:/temp" ) ); s.Add( new FileInfo( "c:/temp" ) ); Console.WriteLine( s.Count ); C#, test fails: string path = "/tmp/filename.txt"; FileInfo f = new FileInfo( path ); File.CreateText( path ).Dispose(); Assert.True( f.Exists ); f.Delete(); Assert.False( f.Exists ); https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen... Languages have their strengths and weaknesses.
- metaltyphoon 3y ago
  FilInfo doesn’t override Equal operator in C#. HashSet will use it for comparison and those are two different object references so idk what the confusion is here.
  - thangalin 3y ago
    A set is a collection of objects in which order has no significance, and multiplicity is generally also ignored. Observing the code alone, it isn't obvious that two FileInfo instances having the same path are themselves not equal. As has been mentioned elsewhere, FileInfo should not be hashable to prevent declaring it as a Set, avoiding the situation entirely. C# isn't flawless. Java isn't flawless.
bad_user 3y ago
C# does not have virtual threads. What C# has is async/await. Which was nice for its time, but at the same time it's an error prone design, as computations should never start async by accident, blocking should be the default. C# also has no useful interruption model. Java's interruption model is error prone, but at least you can work with it. Async/await also splits the standard library and the ecosystem in 2 (blocking vs non-blocking, or blue vs red), and it can't automatically update the behavior of old code. The introduction of virtual threads in Java also works well with "structured concurrency", as seen with Kotlin's Coroutines. Kotlin's approach to concurrency is also superior to that of C#, actually. But what's interesting about Java is that its evolution is often one that involves runtime changes, lifting all boats. Java engineers preferred pushing more changes in the runtime, and somewhat ironically, the JVM ended up being the true multi-language runtime. Java is a good case study of how languages should evolve. It has extreme backwards compatibility, and features being pushed are assessed for how they impact the whole ecosystem, including libraries or languages not in Oracle's control. Project Loom was developed in the open, compared to what Microsoft usually does.
- neonsunset 3y ago
  Do give async/await in C# a try, it has all the structured concurrency features other languages have to invent APIs and special syntax for :) (if you want to take a look at good structured concurrency, you might be interested in Swift implementation)
  - bad_user 3y ago
    I worked with C# professionally. The async/await syntax works with the language's other statements, but for a long time it had gotchas. It doesn't qualify as "structured concurrency", and it has the aforementioned issues — it's (accidentally) error-prone, it splits the ecosystem in two, and has no interruption model. I am not familiar with Swift, but I think you can hardly beat Kotlin's implementation. This is a good introduction from Kotlin's lead: https://www.youtube.com/watch?v=Mj5P47F6nJg https://www.youtube.com/watch?v=Mj5P47F6nJg
    - 3y ago
kaba0 3y ago
You can’t decide language superiority by the number of features. While C# indeed has many cool features, I do think it has already went into C++ territory where all the different, independently cool features have very non-trivial interactions that make it very hard to reason about. Also, async-await is not a good thing — virtual threads are superior in every way in case of a managed language.
- neonsunset 3y ago
  Why async/await is not a good thing? What makes green threads better? Do you know the difference, the issues async/await addresses that green threads simply do not?
  - pjmlp 3y ago
    Read David Fowler's guidelines.
    - winter_blue 3y ago
      Do you have link to any specific article of his (on virtual threads vs async)?
      - pjmlp 3y ago
        Here, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398
  - kamma4434 3y ago
    Because they were created to manually run multiple threads on one physical thread, which is the kind of decoupling that a VM/OS is supposed to do for you.
  - tomp 3y ago
    This is code with async/await: async fn read_file(filename): f = await os.open(filename) let data = f.read() await f.close() return data this is equivalent code with green threads: fn read_file(filename): f = os.open(filename) let data = f.read() f.close() return data As you can see, async/await is pure syntactic noise, it doesn't convey any important meaning.
pjmlp 3y ago
C# is turning into C++, sadly. It appears every six months there must be new language features being added. The last one, for declaring fixed size arrays in structs, with an annotation instead of proper grammar change is getting ridiculous.
kamma4434 3y ago
Async/await is an inferior product compared to threads, for so many reasons (function coloring and meaningful stack traces come to my mind). Keeping the same interface as native thread, plus structured concurrency, are best of breed. Many uncancellable threads + mutability + goroutine panic kill it all are serious issues for golang.
imtringued 3y ago
Java 21 doesn't retrofit green threads though. Quasar [0] is a library that implemented fibers for Java and the main developer pron has joined the OpenJDK development team. All that was necessary for first party support is to make the JDK libraries yield when blocking. Adopting async isn't impossible at all, there is very little demand for it. [0] https://docs.paralleluniverse.co/quasar/ https://docs.paralleluniverse.co/quasar/

throy930493 3y ago

C# is a better language, but the JVM is a significantly better ecosystem. Java will always be behind (and type erasure for generics is annoying enough as someone who started in C# that I don't think it will ever catch up) but between hotspot and being the preferred language of 2/3rds of the clouds I think it clearly wins.

deleted 3y ago
[deleted]
anoy8888 3y ago
If you like jvm, use closure instead.
- hmottestad 3y ago
  Sorry you’re down voted. Closure might not be what the author is looking for. There are a lot of languages you can use with the JVM, Closure is one of them, Groovy, Scala and Kotlin are some more. Kotlin is gaining a lot of traction, especially since it’s backed by JetBrains.
  - sgt 3y ago
    Clojure*
- deleted 3y ago
  [deleted]
bcrosby95 3y ago
Type erasure is why there's such a rich ecosystem of 3rd party languages that run on the jvm.
- bmm6o 3y ago
  Meaning that it would be harder for those languages on the clr because of generics? Would typing all generics as Object not be essentially equivalent?
throwaway2037 3y ago
type erasure for generics is annoying I too have spent significant time programming in both C# and Java. This complaint about type erasure in Java: When does it affect your daily life? There are so many craft workarounds available now that it hardly comes up anymore. Also, would your opinion of Java significantly change if type erasure was removed or never existed?
- throy930493 3y ago
  I have much more experience in C# then Java FWIW, so you're welcome to take my opinions with a grain of salt. I've had a couple of really annoying errors with Beam serializers that took me way longer to debug then I thought was worthwhile. I think it is a worse choice, it's too ingrained in the language and ecosystem to change. That and a couple of other nits would likely make me pick Java over C# or Go if I was starting a new project going forward.

ecshafer 3y ago

F# is far superior to C# as a language. If you are going to jump to the .NET runtime that's the tool to go for.

ZeroClickOk 3y ago
apples and oranges

thangalin 3y ago

Java, prints 1: Set<File> s = new HashSet<File>(); s.add( new File( "c:/temp" ) ); s.add( new File( "c:/temp" ) ); System.out.println( s.size() ); C#, prints 2: ISet<FileInfo> s = new HashSet<FileInfo>(); s.Add( new FileInfo( "c:/temp" ) ); s.Add( new FileInfo( "c:/temp" ) ); Console.WriteLine( s.Count ); C#, test fails: string path = "/tmp/filename.txt"; FileInfo f = new FileInfo( path ); File.CreateText( path ).Dispose(); Assert.True( f.Exists ); f.Delete(); Assert.False( f.Exists ); https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen... Languages have their strengths and weaknesses.

metaltyphoon 3y ago
FilInfo doesn’t override Equal operator in C#. HashSet will use it for comparison and those are two different object references so idk what the confusion is here.
- thangalin 3y ago
  A set is a collection of objects in which order has no significance, and multiplicity is generally also ignored. Observing the code alone, it isn't obvious that two FileInfo instances having the same path are themselves not equal. As has been mentioned elsewhere, FileInfo should not be hashable to prevent declaring it as a Set, avoiding the situation entirely. C# isn't flawless. Java isn't flawless.

bad_user 3y ago

C# does not have virtual threads. What C# has is async/await. Which was nice for its time, but at the same time it's an error prone design, as computations should never start async by accident, blocking should be the default. C# also has no useful interruption model. Java's interruption model is error prone, but at least you can work with it. Async/await also splits the standard library and the ecosystem in 2 (blocking vs non-blocking, or blue vs red), and it can't automatically update the behavior of old code. The introduction of virtual threads in Java also works well with "structured concurrency", as seen with Kotlin's Coroutines. Kotlin's approach to concurrency is also superior to that of C#, actually. But what's interesting about Java is that its evolution is often one that involves runtime changes, lifting all boats. Java engineers preferred pushing more changes in the runtime, and somewhat ironically, the JVM ended up being the true multi-language runtime. Java is a good case study of how languages should evolve. It has extreme backwards compatibility, and features being pushed are assessed for how they impact the whole ecosystem, including libraries or languages not in Oracle's control. Project Loom was developed in the open, compared to what Microsoft usually does.

neonsunset 3y ago
Do give async/await in C# a try, it has all the structured concurrency features other languages have to invent APIs and special syntax for :) (if you want to take a look at good structured concurrency, you might be interested in Swift implementation)
- bad_user 3y ago
  I worked with C# professionally. The async/await syntax works with the language's other statements, but for a long time it had gotchas. It doesn't qualify as "structured concurrency", and it has the aforementioned issues — it's (accidentally) error-prone, it splits the ecosystem in two, and has no interruption model. I am not familiar with Swift, but I think you can hardly beat Kotlin's implementation. This is a good introduction from Kotlin's lead: https://www.youtube.com/watch?v=Mj5P47F6nJg https://www.youtube.com/watch?v=Mj5P47F6nJg
  - 3y ago

kaba0 3y ago

You can’t decide language superiority by the number of features. While C# indeed has many cool features, I do think it has already went into C++ territory where all the different, independently cool features have very non-trivial interactions that make it very hard to reason about. Also, async-await is not a good thing — virtual threads are superior in every way in case of a managed language.

neonsunset 3y ago
Why async/await is not a good thing? What makes green threads better? Do you know the difference, the issues async/await addresses that green threads simply do not?
- pjmlp 3y ago
  Read David Fowler's guidelines.
  - winter_blue 3y ago
    Do you have link to any specific article of his (on virtual threads vs async)?
    - pjmlp 3y ago
      Here, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398
- kamma4434 3y ago
  Because they were created to manually run multiple threads on one physical thread, which is the kind of decoupling that a VM/OS is supposed to do for you.
- tomp 3y ago
  This is code with async/await: async fn read_file(filename): f = await os.open(filename) let data = f.read() await f.close() return data this is equivalent code with green threads: fn read_file(filename): f = os.open(filename) let data = f.read() f.close() return data As you can see, async/await is pure syntactic noise, it doesn't convey any important meaning.

pjmlp 3y ago

C# is turning into C++, sadly. It appears every six months there must be new language features being added. The last one, for declaring fixed size arrays in structs, with an annotation instead of proper grammar change is getting ridiculous.

kamma4434 3y ago

Async/await is an inferior product compared to threads, for so many reasons (function coloring and meaningful stack traces come to my mind). Keeping the same interface as native thread, plus structured concurrency, are best of breed. Many uncancellable threads + mutability + goroutine panic kill it all are serious issues for golang.

imtringued 3y ago

Java 21 doesn't retrofit green threads though. Quasar [0] is a library that implemented fibers for Java and the main developer pron has joined the OpenJDK development team. All that was necessary for first party support is to make the JDK libraries yield when blocking. Adopting async isn't impossible at all, there is very little demand for it. [0] https://docs.paralleluniverse.co/quasar/ https://docs.paralleluniverse.co/quasar/