Hacker News new | past | comments | ask | show | jobs | submit login

C# is actually a pretty good language. It has functional features, even if not as extensive as F#, and has an OO system that is much more well thought out than Java.



If functional is what is needed, and C# is your only option, then this will help [1]

Disclaimer: I'm the author

[1] https://github.com/louthy/language-ext/


Given that C# and Java have copied features from each other throughout the years, and as someone that uses both stacks since their introduction, I wonder what well thought OO features does C# have that Java lacks.


It’s just cleaner and less verbose; eg interfaces can be implemented privately outside of the class namespace, generics are reified, etc... But then there are things like Extension methods, for example, which are incredibly useful.


Generics being reified are a CLR feature available to any .NET language (which Java in the form of J# could take advantage of [0]), don't have anything to do with C# OOP model per se, and were an impediment to properly implement Scala.NET.

This will be fixed on Java side, with value specializations as per Valhala roadmap.

Extension methods are also a way to create lots of spaghetti code, trying to track down where the method is actually implemented.

Swift and Kotlin codebases are good examples on how one can go a bit too far with extension methods.

Java's solution is to offer default interface methods as an approach to traits, which was copied by C# 8.

Regarding interfaces, if you mean explicit interface implementations, besides forcing casts everywhere I don't see what is so well thought out about them.

[0] - https://docs.microsoft.com/en-us/archive/blogs/gauravseth/cu...


Generics being reified in the CLR are entirely biased to C# (and vice versa), which is exactly why they impeded scala.net. They were simply designed for each other.

Extensions methods are great, tracking down the methods that you are calling is super easy in an IDE. The ability to abstract over generic type parameters as well as class subtype is very useful.

Default interface implementations have no connection to extension methods, they solve different problems.

Explicit method implementations are great at avoiding name collisions as well as accidental ones. The coercions needed are not hard casts, though C# could do be improved with a soft cast operator.


CLR is called Common Language Runtime and not C# Language Runtime.

In fact, C++/CLI is the only Microsoft language that has full access to all CLR features, not C#.

A language that has a much more expressive OO model than either Java or C#, and requires reiffed generics.

IDEs don't work in code review workflows.


For all intensive purposes, the CLR evolves with C# in lockstep. Multi language might have been a goal at one time, but isn’t really anymore. No one really uses C++ CLI.

> IDEs don't work in code review workflows.

Use or make better tools.


You should come out from your Ivory tower.

Thousands of developers use F#, VB.NET, Powershell, C++/CLI every day, and to lesser extent Cobol and Fortran compilers for .NET.

C++/CLI support was a must have requirement for .NET Core adoption, not only because of externals, because all .NET UI Frameworks make use of C++/CLI.

So much for no one really uses.

We use the tools our customers are willing to pay for.

Care to provide a link to a code review tool with IDE like capabilities for code navigation?


Valhalla won't solve all issues with erased generics in Java. In C# "static T foo;" is a valid declaration that creates a separate "foo" for each specialized class.


Only if T is a value type, reference types share implementations.

The final semantics for specialized value types are not yet set in stone, so what Java might end up supporting is still a guessing game.


> eg interfaces can be implemented privately outside of the class namespace

Not sure what you're referring to here (you can implement interfaces of other packages in Java), but everything else you mentioned is not related to C#/Java's OO system.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: