4 ms·

>Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so

>Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so long we already have tools like Immutables and Lombok to get past this really dumb limitation in Java. All the ones you named are fairly new languages, and C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? Java historically has been very conservative with implementing things because they usually try to get it right (generics non-withstanding). For that matter C# rushed into a few things too and screwed the pooch badly on them.

nightski 7y ago
I'd be curious which features you think C# messed up on. I have been using C# professionally since 2000 in it's first beta and can't think of a newer feature that would meet this criteria? That said you are correct about records. Although it is getting them also.
- anthonybsd 7y ago
  The one that annoys me the most in C# on a day-to-day basis is Nullable<T>. Java took their time with Optional<T> but once it was released it was great. Can be used in lambdas, all libraries are modified and aware of it etc. C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
  - wvenable 7y ago
    In both C# and Java, reference types are nullable. Nullable<T> exists in C# to provide for nullable value types. It's not comparable to Optional<T> as that's an entirely different feature.
    - anthonybsd 7y ago
      They aren’t “entirely different feature”. Why do you think C#8 introduced Nullable reference types that work exactly like Java Optional ? https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...
  - elfexec 7y ago
    > C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you. You are completely missing the point of Nullable. It was introduced because databases allowed int, float, etc ( value types ) to be null. It was never meant to be an Option type. Reference types are already "nullable" so the database returning null for strings wasn't a problem. But databases returning nulls for int was a problem. It led to performance issues ( boxing and/or adding additional code to marshal data from one source to another ). If you find Nullable to be annoying then you either don't code in C# much and you especially don't deal with data/databases. For what it was intended for, Nullable did it's job. And if Nullable is your only complaint, given the extraordinary changes that C# has gone through, I think it speaks well for C#.
    - anthonybsd 7y ago
      > You are completely missing the point of Nullable Am I? Apparently so is everyone else because Microsoft has re-worked Nullable<T> in C# 8 to be almost exactly like Java Optional! Silly me right?
      - wvenable 7y ago
        Nullable/Non-nullable reference types in C# 8.0 having nothing to do with Nullable<T> and aren't even implemented using it. C# 8.0 implementation of something like Optional<T> for reference types uses static flow analysis to ensure correct use of potentially null values. That's vastly superior in every way to Optional<T>.
        anthonybsd 7y ago
        Ah yes “superior in every way”. Was wondering when the myopic zealots would come out.
        wvenable 7y ago
        Yes, because it's checked by the compiler using normal constructs. someNullableInstance.DoSomething(); // compiler error if (someNullableInstance != null) someNullableInstance.DoSomething(); // not an error Option<T> is fine but it's a lot of syntax to use correctly.
shawnz 7y ago
C# does not have records but they have been "proposed" and subsequently delayed for some time now.
GordonS 7y ago
> C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? How would you compare records to c# language features then? Are records value or ref types? Do they live in the stack or the heap?
- anthonybsd 7y ago
  Reference; heap; They are data containers, not control structures.
  - GordonS 7y ago
    Can't you use structs in C# as data containers?
    - anthonybsd 7y ago
      Ughh, you can provided that they are 1) Small 2) Short lived. Because they live on the stack and follow the rules of value types you really shouldn't be using them for anything major. I.e. you want to model a SQL query result for a table with more than 3 columns? Probably struct is NOT the way to go, use a POCO class.
      - GordonS 7y ago
        C# structs don't always live on the stack (unless you use a ref struct)[0] [0] https://kalapos.net/Blog/ShowPost/DotNetConceptOfTheWeek16-RefStruct https://kalapos.net/Blog/ShowPost/DotNetConceptOfTheWeek16-R...
        anthonybsd 7y ago
        Well of course. Just like an int doesn't always live on the stuck. I.e. when it's declared as a field for example. If you are piping data from SQL DB into a List<YourStruct> the list is a reference type and will of course be on the heap. Another issue with struct being big is really when it's being passed around and value copying starts to occur. You want to minimize this if the struct is large. My point being is that if in doubt, you probably don't want to use a struct and hence it's not a general purpose data container.

nightski 7y ago

I'd be curious which features you think C# messed up on. I have been using C# professionally since 2000 in it's first beta and can't think of a newer feature that would meet this criteria? That said you are correct about records. Although it is getting them also.

anthonybsd 7y ago
The one that annoys me the most in C# on a day-to-day basis is Nullable<T>. Java took their time with Optional<T> but once it was released it was great. Can be used in lambdas, all libraries are modified and aware of it etc. C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
- wvenable 7y ago
  In both C# and Java, reference types are nullable. Nullable<T> exists in C# to provide for nullable value types. It's not comparable to Optional<T> as that's an entirely different feature.
  - anthonybsd 7y ago
    They aren’t “entirely different feature”. Why do you think C#8 introduced Nullable reference types that work exactly like Java Optional ? https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...
- elfexec 7y ago
  > C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you. You are completely missing the point of Nullable. It was introduced because databases allowed int, float, etc ( value types ) to be null. It was never meant to be an Option type. Reference types are already "nullable" so the database returning null for strings wasn't a problem. But databases returning nulls for int was a problem. It led to performance issues ( boxing and/or adding additional code to marshal data from one source to another ). If you find Nullable to be annoying then you either don't code in C# much and you especially don't deal with data/databases. For what it was intended for, Nullable did it's job. And if Nullable is your only complaint, given the extraordinary changes that C# has gone through, I think it speaks well for C#.
  - anthonybsd 7y ago
    > You are completely missing the point of Nullable Am I? Apparently so is everyone else because Microsoft has re-worked Nullable<T> in C# 8 to be almost exactly like Java Optional! Silly me right?
    - wvenable 7y ago
      Nullable/Non-nullable reference types in C# 8.0 having nothing to do with Nullable<T> and aren't even implemented using it. C# 8.0 implementation of something like Optional<T> for reference types uses static flow analysis to ensure correct use of potentially null values. That's vastly superior in every way to Optional<T>.
      - anthonybsd 7y ago
        Ah yes “superior in every way”. Was wondering when the myopic zealots would come out.
        wvenable 7y ago
        Yes, because it's checked by the compiler using normal constructs. someNullableInstance.DoSomething(); // compiler error if (someNullableInstance != null) someNullableInstance.DoSomething(); // not an error Option<T> is fine but it's a lot of syntax to use correctly.

shawnz 7y ago

C# does not have records but they have been "proposed" and subsequently delayed for some time now.

GordonS 7y ago

> C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? How would you compare records to c# language features then? Are records value or ref types? Do they live in the stack or the heap?

anthonybsd 7y ago
Reference; heap; They are data containers, not control structures.
- GordonS 7y ago
  Can't you use structs in C# as data containers?
  - anthonybsd 7y ago
    Ughh, you can provided that they are 1) Small 2) Short lived. Because they live on the stack and follow the rules of value types you really shouldn't be using them for anything major. I.e. you want to model a SQL query result for a table with more than 3 columns? Probably struct is NOT the way to go, use a POCO class.
    - GordonS 7y ago
      C# structs don't always live on the stack (unless you use a ref struct)[0] [0] https://kalapos.net/Blog/ShowPost/DotNetConceptOfTheWeek16-RefStruct https://kalapos.net/Blog/ShowPost/DotNetConceptOfTheWeek16-R...
      - anthonybsd 7y ago
        Well of course. Just like an int doesn't always live on the stuck. I.e. when it's declared as a field for example. If you are piping data from SQL DB into a List<YourStruct> the list is a reference type and will of course be on the heap. Another issue with struct being big is really when it's being passed around and value copying starts to occur. You want to minimize this if the struct is large. My point being is that if in doubt, you probably don't want to use a struct and hence it's not a general purpose data container.