What are the features that c# is missing?
As the other comment explained delegates are the equivalent of anonymous inner classes and are far better.
Checked exceptions are really a nuisance, I would call them a negative feature.
Java enums in c# are basically classes with readonly properties if you need to pass constructor arguments.
Streams in Java are a huge clusterfuck.
I can't think to anything that Java has that is better than c#.
Delegates are not the equivalent of anonymous inner classes. They're commonly used for similar design patterns (observer and other callbacks), yes, but they're not the same thing. To be more specific, an anonymous delegate / lambda can be thought of as an implementation of an interface with a single method. But with Java anonymous inner classes, you can implement multiple methods at once.
The reasons why Java enums are better, is because they're actually constrained to the domain you specify. In C#, the range of values for any enum is the same as its underlying integer type - it's just that some of those values have names, while others don't. But it's always legal to cast (and few people know this, but 0 is always a valid enum value that you don't need to cast) - so any method you write that accepts an enum value has to validate it. In Java, since enum is basically a final class with a bunch of private singletons, you are guaranteed that the reference you get points to one of those.
That said, given that C# now has pattern matching, and it seems to be getting more powerful with every release, I'd be surprised if it didn't get something like case classes very soon.
Delegates and anonymous inner classes are equivalent, modulo API:
//Java
Bax.addHandler(new Foo()
{
@Override
public void Bar()
{
doSomething();
}
@Override
public int Baz(X n)
{
return computeInt(n);
}
});
//C#
Bax.AddHandler(() => DoSomething(), n => ComputeInt(n));
But, anonymous delegates and lambdas are at once syntactically nicer and more powerful, because of type inference and the fact that they can capture local variables.
Regarding Java enums, the actual equivalent feature in C# is class nesting. There is a tiny bit more ceremony involved in defining them, but they're more flexible than Java enums. For instance, you can decide whether or not to implement them as readonly (final) fields, or as static properties, depending on how much you care about cache friendliness.
public abstract partial class SomeEnum
{
private SomeEnum(){}
public abstract int Biz();
sealed class AFoo : SomeEnum { public override Biz() => 2 }
sealed class ABar : SomeEnum { public override Biz() => 4 }
sealed class ABaz : SomeEnum { public override Biz() => 8 }
}
//Singleton implementation:
public abstract partial class SomeEnum
{
public static readonly SomeEnum Foo = new AFoo();
public static readonly SomeEnum Bar = new ABar();
public static readonly SomeEnum Baz = new ABaz();
}
//Cache friendly implementation:
public abstract partial class SomeEnum
{
public SomeEnum Foo => new AFoo();
public SomeEnum Bar => new ABar();
public SomeEnum Baz => new ABaz();
}
It's also worth noting that extension methods on C# enums give you most (all?) of the power of Java enums.
That is only equivalent within the boundaries of your API (i.e. when you use them as pure callbacks). But your delegates are two different objects, while in the Java example, it's a single object. This makes a difference if, for example, object identity matters.
From practical purpose, Java anonymous classes can be used in any scenario where you need to create a one-off object that derives from a class or implements one interface. A delegate can only be used in a scenario where the receiving variable or function wants a function type.
I'm not arguing that delegates are lambdas are bad, mind you. For the common scenario involving callbacks, they're vastly superior. But they're not a complete replacement for Java inner classes.
But they aren't really anonymous then, since you have to write a wrapper class for every class or interface that you intend to implement inline.
By the way, I totally forgot about F# object expressions! But they're a good example of this feature. Better than in Java, in fact, because they let you implement multiple interfaces. Also, IIRC, they're true closures (whereas Java only lets you close over finals, not writable locals).
Ideally, you'd have both those and lambdas in a language, like C# and Scala do. If I had to choose, though, I'd definitely pick lambdas - that is the 90% use case.
Brevity is the feature, not anonymity. What C# actually lacks is syntax sugar. But, a few years ago, I spent an hour or so implementing `Ad-hoc` classes for most of the interfaces and abstract classes that I thought I would ever need, and it's been sufficient over 90% of the time[1]. N.b. these classes could have been generated programmatically.
I'm not claiming that the technique is exactly equal to what Java gives you out of the box, but rather that C# can get within epsilon. In other words, for my purposes, the prefix AdHoc- might as well be a keyword (as in AdHocIEquality<T>, AdHocIEnumerable<T>†, AdHocDisposable, AdHocHttpHandler, etc...), because it's indistinguishable from syntax sugar.
On the other hand, the F# object expression really is more than just syntax sugar, because of the way it interacts with type inference (no need to upcast to satisfy the type checker), and (as you noted) that it can implement an arbitrary set of interfaces. But, it's not all carrots and apples: F# lambdas don't work well with protected members. Meanwhile, C# can close over just about anything (a ref local, such as Span<T>, being the obvious exception).
On your delegates example for C#, since the parameters of the lambda and methods match, and you aren't relying on any closure behaviour, you can use 'method group syntax' to make it even more succinct:
> An actual roadmap to rewrite remaining C++ from OpenJDK in Java
Very cool. I wasn't aware of that. Do you think this will help introduce more "low level" features in Java since it is paramount to at least keep the same level of performance, and definitely improve it in the future?
Note that I wasn't completely fair, the .NET team also has some plans to incrementally move the runtime into C#, but so far it has only been mentioned on an InfoQ interview, no official plans revealed.
"So, in my view, the primary trend is moving our existing C++ codebase to C#. It makes us so much more efficient and enables a broader set of .NET developers to reason about the base platform more easily and also contribute."
> What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better.
Not entirely. .NET delegates don't support generic type parameters (aka first-class polymorphism). Methods in C# and Java do.
C# interfaces also don't support static methods, which are useful for factory patterns. C#'s factory patterns require a lot more code as a result.
C# also has a bunch of artificial limitations, like not being able to specify type constraints on Delegate, Enum, and a few other built-in types. It's just nonsense.
The rest of C# is overall better than Java though.
There is no delegate equivalent of passing around an instance of IFoo:
interface IFoo
{
void Bar<T>();
}
This is known as first-class polymorphism.
Classes with methods are strictly more powerful than delegates, but they shouldn't be. It's even worse than that actually, because you can't even create an open instance delegate to a generic interface or abstract class method (you'll get a runtime error, not even a static error).
