4 ms·

Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads

Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.

joe_mwangi 19d ago
Typeclasses caught me by surprise. Smart move by the java team.
troupo 19d ago
Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods. Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#. - Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes. - object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable. - extension methods. - named and optional arguments in functions - null coalescing operator - generics over primitive types (unless it was already implemented, I remember seeing a JEP about it) - async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax. - (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime - .... definitely a bunch more I don't remember at this point ...
- za3faran 19d ago
  > Proper IEnumerable with proper iterators that in turn enables Linq Are you referring to generators? > Properties As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view. > object initialisers I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. > extension methods Typeclasses are currently being explored, which are a superior approach. > named and optional arguments in functions Those would be nice (at least named arguments). I can see how optional arguments could complicate things. > generics over primitive types As you mentioned, it's in the works > async/await... verbiage could still probably be hidden behind a friendlier syntax The approach they took does not need any extra syntax.
  - troupo 18d ago
    > Are you referring to generators? Both I guess. Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerable-1?view=net-10.0 https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library. > I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. This is mostly due language design. Java heavily relies on properties and provides no facilities for them. Hence the builder pattern instead of object initializers. In C# object initializers synergize with properties: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > The approach they took does not need any extra syntax. You mean it needs 15 lines whete C# needs one? ;)
    - za3faran 18d ago
      > You mean it needs 15 lines whete C# needs one? ;) Can you elaborate? The async/await approach is much more than 1 line when you need to switch a call between them. Whereas the green thread approach does not need anything.
      - troupo 18d ago
        What's Java's equivalent of x = await someFunction() await waitForSomeOtherFunction() (both are async)
        gf000 18d ago
        As mentioned: var x = someFunction() waitForSomeOtherFunction() That's semantically equivalent in the two languages.
- gf000 19d ago
  At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features. That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. (And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)
  - troupo 18d ago
    > a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)
    - gf000 18d ago
      While typing this comment I pressed/swiped on several words to finish them. One reads much faster than they write, I don't really see a problem with easily guessable auto complete.
      - troupo 17d ago
        Even if you read much faster than you type, it's easier to read fewer lines of code than dozens of plumbing boilerplate.
        gf000 16d ago
        Sure, we can find factors for "verbosity increase" and "difficulty to understand a line" where what you say is also true. I think that java found a decent spot where both factors are low. It's not a particularly verbose language, especially in modern times (records, type inference, I even mention lambdas because some people live in caves), like if you do POJOs and stuff with getter setters than you get a no information increasing extra 3+3 lines of code per field and that's most of it. Method bodies are not more verbose than other typical languages.
- samus 18d ago
  > - object initialisers Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler. > - extension methods. They make code harder to understand. If they ever come they would have to be declared at the top of each source file. > - null coalescing operator Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner. > - async/await There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code. > - ... generics metadata in runtime There are plans to add a kind of reified generics, so maybe we'll get it.
  - troupo 18d ago
    > Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there is no simpler syntax than plain old synchronous code. But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... Java always opts out for "let the developer handle all the complexity all the time even for the simplest most used parts of the code".
    - gf000 18d ago
      > And thousands of manual get/set functions don't? By definition, they don't. They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. > But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds
- jayd16 18d ago
  Good list. - Value types is a huge one to add if we're looking at what is actually in the wild. - Scopeless `using` declarations are nice for RAII like behavior. - IMO C# builds are actually way way nicer than Java. Sln and .csproj files and nuget are actually a lot easier to deal with than javac/ant/mvn/Gradle. Maybe that's more a .NET thing than a C# feature.
jayd16 18d ago
Even in the small list of features in your retort you had to switch to future tense.
- za3faran 18d ago
  Value types are scheduled to be in preview next release (6 months). And C# does not have type classes.

joe_mwangi 19d ago

Typeclasses caught me by surprise. Smart move by the java team.

troupo 19d ago

Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods. Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#. - Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes. - object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable. - extension methods. - named and optional arguments in functions - null coalescing operator - generics over primitive types (unless it was already implemented, I remember seeing a JEP about it) - async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax. - (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime - .... definitely a bunch more I don't remember at this point ...

za3faran 19d ago
> Proper IEnumerable with proper iterators that in turn enables Linq Are you referring to generators? > Properties As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view. > object initialisers I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. > extension methods Typeclasses are currently being explored, which are a superior approach. > named and optional arguments in functions Those would be nice (at least named arguments). I can see how optional arguments could complicate things. > generics over primitive types As you mentioned, it's in the works > async/await... verbiage could still probably be hidden behind a friendlier syntax The approach they took does not need any extra syntax.
- troupo 18d ago
  > Are you referring to generators? Both I guess. Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerable-1?view=net-10.0 https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library. > I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. This is mostly due language design. Java heavily relies on properties and provides no facilities for them. Hence the builder pattern instead of object initializers. In C# object initializers synergize with properties: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > The approach they took does not need any extra syntax. You mean it needs 15 lines whete C# needs one? ;)
  - za3faran 18d ago
    > You mean it needs 15 lines whete C# needs one? ;) Can you elaborate? The async/await approach is much more than 1 line when you need to switch a call between them. Whereas the green thread approach does not need anything.
    - troupo 18d ago
      What's Java's equivalent of x = await someFunction() await waitForSomeOtherFunction() (both are async)
      - gf000 18d ago
        As mentioned: var x = someFunction() waitForSomeOtherFunction() That's semantically equivalent in the two languages.
gf000 19d ago
At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features. That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. (And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)
- troupo 18d ago
  > a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)
  - gf000 18d ago
    While typing this comment I pressed/swiped on several words to finish them. One reads much faster than they write, I don't really see a problem with easily guessable auto complete.
    - troupo 17d ago
      Even if you read much faster than you type, it's easier to read fewer lines of code than dozens of plumbing boilerplate.
      - gf000 16d ago
        Sure, we can find factors for "verbosity increase" and "difficulty to understand a line" where what you say is also true. I think that java found a decent spot where both factors are low. It's not a particularly verbose language, especially in modern times (records, type inference, I even mention lambdas because some people live in caves), like if you do POJOs and stuff with getter setters than you get a no information increasing extra 3+3 lines of code per field and that's most of it. Method bodies are not more verbose than other typical languages.
samus 18d ago
> - object initialisers Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler. > - extension methods. They make code harder to understand. If they ever come they would have to be declared at the top of each source file. > - null coalescing operator Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner. > - async/await There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code. > - ... generics metadata in runtime There are plans to add a kind of reified generics, so maybe we'll get it.
- troupo 18d ago
  > Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there is no simpler syntax than plain old synchronous code. But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... Java always opts out for "let the developer handle all the complexity all the time even for the simplest most used parts of the code".
  - gf000 18d ago
    > And thousands of manual get/set functions don't? By definition, they don't. They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. > But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds
jayd16 18d ago
Good list. - Value types is a huge one to add if we're looking at what is actually in the wild. - Scopeless `using` declarations are nice for RAII like behavior. - IMO C# builds are actually way way nicer than Java. Sln and .csproj files and nuget are actually a lot easier to deal with than javac/ant/mvn/Gradle. Maybe that's more a .NET thing than a C# feature.

jayd16 18d ago

Even in the small list of features in your retort you had to switch to future tense.

za3faran 18d ago
Value types are scheduled to be in preview next release (6 months). And C# does not have type classes.