6 ms·

Silly question. If you want the C# experience but more community/OSS driven… why not Java?

neonsunset 1y ago
[dead]
bradford 1y ago
I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were: 1. The overall architecture (with the JVM) made it slower than the equivalent C# code. 2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then. (Not OP, disclaimer, I work for Microsoft and this is only my opinion).
- DarkNova6 1y ago
  Ah, got you. > I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were: It's almost a shame. I am genuinely impressed with the gains the team has made in both, language aspects as well as JVM technology. They have some brilliant people working on it and I love to hear their talks (Brian Goetz and Mark Reinhold, mostly). But I suppose I would say the same about .Net, it's just that you guys have much less public exposure of your internal reasoning.
  - throw234234234 1y ago
    I've seen the gains in Java; the main things that would close the gap are not yet there in Java. .NET code, especially when tuned, still has significantly more knobs in your code to tune and make faster. An example would be proper generics with value types together means less boxing in generic code in general overall but there's a lot more I can think of. I've seen almost 50% of gains, particuarly when doing math like code, of moving away from Java to .NET especially if the jump to C/C++/Rust is too much for the team in question due to other requirements.
wvenable 1y ago
C# and Java might be similar technologies at some level but they not similar developer experiences at all.
- DarkNova6 1y ago
  How so? It striked me that the .Net library and Java frameworks like Spring or Quarkus are virtually identical.
  - wvenable 1y ago
    There's more to developer experience than that. Your comment even demonstrates one of the differences: The .NET library compared to a bunch of different Java frameworks.
    - DarkNova6 1y ago
      That is indeed a technical difference. But I don’t see much significance in it. Spring is a de-facto extension of the core java libraries and alternatives like Quarkus follow the same mental model with a better technological foundation.
      - wvenable 1y ago
        The culture around Java and C# are very different. I'm not sure I can explain it. I could continue to point hundreds of technical differences but that's the trees and not the forest.
      - donny2018 1y ago
        Maybe, but with all the modern .NET tooling I feel at least 2x productive in .NET than in Spring Boot. There are a lot of quality of life stuff in .NET/C# that really does add up and makes a substantial difference (DX-wise) in the long run.
Kwpolska 1y ago
C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.
- osigurdson 1y ago
  I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.
  - Kwpolska 1y ago
    What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.
    - osigurdson 1y ago
      I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.
      - kbolino 1y ago
        > I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today. Have you never written a plugin or a mod? Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features. As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them). If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.
raddan 1y ago
I wouldn't call this a silly question at all. But having recently converted my intro data structures course from Java to C#, I can talk about why C# might be better. I have programmed regularly in both languages for the last 15 or so years (in addition to regularly programming in TypeScript, Scala, and F#). Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow. To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like. Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases! Some C# niceties: * Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there. * Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object! * The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool). * By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming. * switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language. * Speaking of... LINQ! * In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>. * Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful. * Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time. * C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun. * .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things. * NuGet is a million times easier to use than Maven. The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually. Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.
raw_anon_1111 1y ago
The thing that always turned me off about Java are the IDEs. Besides Java doesn’t have anything like LINQ. I would rather have an ecosystem backed by Microsoft than Oracle. Does Java have real generics yet?

[dead]

I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were: 1. The overall architecture (with the JVM) made it slower than the equivalent C# code. 2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then. (Not OP, disclaimer, I work for Microsoft and this is only my opinion).

DarkNova6 1y ago
Ah, got you. > I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were: It's almost a shame. I am genuinely impressed with the gains the team has made in both, language aspects as well as JVM technology. They have some brilliant people working on it and I love to hear their talks (Brian Goetz and Mark Reinhold, mostly). But I suppose I would say the same about .Net, it's just that you guys have much less public exposure of your internal reasoning.
- throw234234234 1y ago
  I've seen the gains in Java; the main things that would close the gap are not yet there in Java. .NET code, especially when tuned, still has significantly more knobs in your code to tune and make faster. An example would be proper generics with value types together means less boxing in generic code in general overall but there's a lot more I can think of. I've seen almost 50% of gains, particuarly when doing math like code, of moving away from Java to .NET especially if the jump to C/C++/Rust is too much for the team in question due to other requirements.

wvenable 1y ago

C# and Java might be similar technologies at some level but they not similar developer experiences at all.

DarkNova6 1y ago
How so? It striked me that the .Net library and Java frameworks like Spring or Quarkus are virtually identical.
- wvenable 1y ago
  There's more to developer experience than that. Your comment even demonstrates one of the differences: The .NET library compared to a bunch of different Java frameworks.
  - DarkNova6 1y ago
    That is indeed a technical difference. But I don’t see much significance in it. Spring is a de-facto extension of the core java libraries and alternatives like Quarkus follow the same mental model with a better technological foundation.
    - wvenable 1y ago
      The culture around Java and C# are very different. I'm not sure I can explain it. I could continue to point hundreds of technical differences but that's the trees and not the forest.
    - donny2018 1y ago
      Maybe, but with all the modern .NET tooling I feel at least 2x productive in .NET than in Spring Boot. There are a lot of quality of life stuff in .NET/C# that really does add up and makes a substantial difference (DX-wise) in the long run.

Kwpolska 1y ago

C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.

osigurdson 1y ago
I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.
- Kwpolska 1y ago
  What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.
  - osigurdson 1y ago
    I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.
    - kbolino 1y ago
      > I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today. Have you never written a plugin or a mod? Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features. As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them). If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.

raddan 1y ago

I wouldn't call this a silly question at all. But having recently converted my intro data structures course from Java to C#, I can talk about why C# might be better. I have programmed regularly in both languages for the last 15 or so years (in addition to regularly programming in TypeScript, Scala, and F#). Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow. To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like. Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases! Some C# niceties: * Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there. * Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object! * The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool). * By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming. * switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language. * Speaking of... LINQ! * In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>. * Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful. * Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time. * C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun. * .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things. * NuGet is a million times easier to use than Maven. The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually. Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.

raw_anon_1111 1y ago

The thing that always turned me off about Java are the IDEs. Besides Java doesn’t have anything like LINQ. I would rather have an ecosystem backed by Microsoft than Oracle. Does Java have real generics yet?