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

How does this compare to the .NET ecosystem?





C# is a better language. Java 8 started to catch up with some of the quality-of-live niceties, but Java has a lot of mistakes baked into the language and interfaces that can't be removed without potentially breaking a lot of stuff, which the consortium is not willing to do. C# and DotNet were designed with the wisdom gained from the early days of Java implementation and sidestepped a lot of these messes.

Java has a substantially better ecosystem. The tooling is just miles ahead of what exists in the DotNet world. Until very recently you developed in Visual Studio and you ran on Windows in production and that was that. They're working on Linux support and a broader ecosystem but they are probably a decade behind what is available on Java. Even stuff like package management is crude, NuGet is a joke compared to Gradle.


The JVM has multiple languages such as Kotlin, Scala and Groovy. Each of them arguably being a better language than Java. That most people still prefer to build projects in Java shows that other things such as backward compability, how many developers know the language, tool chain and so on matters more than the isolated technical merits of the language.

Cannot agree more. Syntactic sugar or certain more advanced constructs in the end have very low ROI for experienced developers, which can utilize very well the existing language features and extend their expressive power with internal DSLs. The costs associated with the tooling, hiring people with necessary expertise etc at that point are more important.

> C# is a better language.

Yep, as a seasoned Java developer I agree. There are times when I miss a part of the Java syntax but they are few and far between.

> Java has a substantially better ecosystem. The tooling is just miles ahead of what exists in the DotNet world.

Also true, although it is getting closer fast.

Possibly more important: they are both in another league compared most other languages. (Of the other languages/stacks I have some production experience with Angular/TypeScript is the only that I feel has anything close to the tooling support that C# and especially Java has.)


> but Java has a lot of mistakes baked into the language and interfaces that can't be removed without potentially breaking a lot of stuff

Absolutely true, but so does C#. In the end it turned out that .NET's reified generics were a mistake (which makes language interop on .NET painful), and more recently async/await.


> In the end it turned out that .NET's reified generics were a mistake

Do you have any resources that explain this point further?

Reified generics have often been praised as the thing that CLR got right (and JVM got wrong). I never understood fully why that is, especially since other languages with generics (e.g. Haskell and OCaml) don't have anything reified (although in all honesty also don't have RTTI so it's really not necessary).


Erasure makes it easy for Java, Kotlin, and Clojure share code and data structures without costly runtime conversions. Languages like Scala and F# have had trouble implementing features on the CLR because of reification, and take a look at what Python and Clojure on the CLR have to go through for interop.

I know some people think that say they like reified generics in C#, but those are mostly people who aren't aware of what cost to the entire ecosystem they're paying in exchange to what is a minor convenience in C#.

BTW, reification of reference-type generics is not to be confused with specializing collections for value types ("arrays-of-struct") an extremely important feature that CLR indeed has, and Java is now working on getting.


"Mistake" is a strong word, and I would disagree with it. But when building extensible libraries and systems I do often find myself wanting to pass around a List<Something<?>>, which isn't doable without writing a second generic interface or the like. On the flip side, in Java (or, these days, Kotlin), a type-erased generic can be mediated more easily because passing a Class is easier than adding a second interface.

Part of it is that a lot of that stuff is gamedev-related, for me. It's not the biggest thing in the world, but for a lot of the stuff I find myself writing in C#, I find myself wishing for type erasure to make throwing data around a little easier. On the other hand, though, when writing web stuff on the JVM--I absolutely will not waste my time doing this in .NET, ASP.NET Core is not very good and EF Core is awful--I often wish for type reification, so it's just a horses-for-courses thing.


Generics interop just fine on .NET, and async/await had become a starting point for similar designs in many other languages. I don't think you'll find many people who actually write code in that ecosystem agreeing with either of those claims.

> Generics interop just fine on .NET

They really don't. They have posed severe restrictions on features in languages like Scala and F#, and take a look at Clojure, Python and JS interop on the JDK as opposed to .NET.

> and async/await had become a starting point for similar designs in many other languages.

And it's a mistake in most of them. Java has copied some of C's mistake, C# has copied some of Java's, and others may copy some of C#. Every language/runtime both repeats others' mistakes and adds a good helping of its own.

> I don't think you'll find many people who actually write code in that ecosystem agreeing with either of those claims.

I can only express my own opinions (and I think reified generics, as implemented in the CLR, is a far bigger mistake than async/await, which only affects the C# language), but I am far from being alone in having them. Also, I have no doubt that async/await is an improvement on the previous situation, which is why people like it, but nevertheless I think it's a mistake as there are alternatives that are more convenient, more general, and have less of an adverse impact on the language (e.g. Go's goroutines).


What are the restrictions on F# that were posed by them? Given that Don Syme was the one who originally designed them, specifically with a mind for cross-language use (which is why they got stuff like variance long before C# supported it), this is a surprising claim. In fact, I recall Don saying something along the lines of, if CLR did generics with erasure like Java, F# probably wouldn't be where it is today.

I saw the link to Clojure page you posted in another comment, but I don't see any fundamental problem with generics there. Yes, if you're invoking a statically typed language from a dynamically typed one, you have to occasionally jump through hoops when dealing with things like method overloads that require types to distinguish. The same goes for Python. I have actually used Python embedded in C# more than once, with interop both ways, and in practice it "just works" most of the time.

Conversely, I don't see why statically typed languages should surrender valuable type information (and associated perf and expressivity gains) for the sake of convenience of dynamically typed ones, especially on the platform where static typing is the norm, and libraries are expected to be designed around it.

As far as async/await vs Go's goroutines - since we're talking about language interop, how many languages can Go coroutines interop with? Async/await easily flows across language boundaries, as you can see in WinRT - any language that has the notion of first-class function values can handle that pattern. Goroutines are essentially a proprietary ABI. And the worst part is that once the language has them, all FFI has to pay the tax to bridge to the outside world, regardless of how much you actually use them. It may be an argument for standardizing some form of green threads on platform ABI level, so that all code on that platform is aware of their existence and capable of handling them. Win32 tried with fibers, without much success. Perhaps it was too early and the design was too flawed, but it's not encouraging.


> What are the restrictions on F# that were posed by them?

It does make it harder to add features to the language that do not map to the current reified "generics" spec, for example higher-kinded polymorphic types.

Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, or switch-on-type, for functional languages.


If such features can be implemented via runtime type erasure on JVM, you can still do that on CLR - it's not like it prohibits that technique, it just doesn't use it for generics. You can even have different languages agree on how they would implement it, so that they could fully interop. With modopt/modreq, you can capture it all in metadata, as well.

It wouldn't interop with C# generics (although I don't see why it couldn't interop with C# by other, less convenient means). But if it can't be properly mapped to them when they're reified, why is there an expectation that it should? It seems to me like the gist of the argument here is that we can conflate two features into one, if only we remove all the conflicting bits of one of the features - which also happens to be the one much more broadly used at the moment. It's a strange trade-off.


> Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations,

That's true (and will be addressed), but that's a problem that can be fixed by adding a feature, not removing a central one, which is why I said that both Java and .NET have made mistakes, and reified generics was one of .NET's.

> or switch-on-type, for functional languages.

There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. Perhaps you mean switching on A<Foo> and A<Bar>, where Foo and Bar are reference types (and possible with a subtype relationship between them), well even Haskell can't do that, and if there was a language that thought this is a good idea, it would be able to do it quite easily.


> That's true (and will be addressed)

Glad to hear it! It's probably the biggest issue trying to do functional programming on the JVM.

> There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes.

The technique to implement ADTs in functional languages on the JVM has often been to add an integer tag to every subtype and switch on that, but it's ugly enough for interop that IIRC Scala doesn't do it (and is thus less efficient).


Packet is a great alternative to the NuGet client.

Tooling might be slightly behind Java's, but honestly, there's not much in it. Dotnet Core might only have been available on Linux for a few years, but Mono was around for many before that.

The dotnet CLI also recently got the concept of 'global tools', which are akin to NPMs.

A lot of work is also underway on better cross-platform performance analysis, crash dump handling and the like for runtime in production[0]

Is there anything in particular you miss?

[0] https://devblogs.microsoft.com/dotnet/introducing-diagnostic...


Maybe not much that the OP miss. But then again there's nothing to miss from Java either since Java fulfill his requirements (maybe more than .NET can).

If I'm a Java developer who has been using Maven for such a long time. I don't see the allure switching to .NET just because NuGet exist or whatever Packet stands for.

The big data ecosystem is all JVM/Java.

Android started off as Java. Sure they have Kotlin now, but I don't know how many developers switching to Kotlin in drives.

Basically, the ecosystem of Java is already _there_ when MSFT is trying to catch it up so experienced Devs (a.k.a people who are already comfortable with the tooling) do not see the reason to switch.

As for me myself, I used to intern at MSFT back in the mid 2000 drinking the .NET kool-aid. One day I woke up and realize that part of the hi-tech world that interest me, relies a lot on OSS and the large portion of OSS was Java. Fast forward to today, FAANG is mostly Java shop. Java seems like a safer ground for me to have a longer career.

That's just me and my 2c. I'm too lazy to switch to .NET since there's no added value at the moment unless if I want to do back-office in-house web-app.


According to the roadmap, Mono's JVM interop used for Xamarin Android will be making its way more directly into .NET Core and will light up on almost every platform, which would give .NET greater, direct access to the Java ecosystem as well.

What about Kotlin?

Why downvote ? C#/Visual Studio is one of the best languages out there.

Lightyears behind it. There's no reason Java is still prevalent besides inertia. .NET/.NET Core is going to slowly but surely overtake it with Java shooting itself in the foot with the new licensing terms and .NET/C#'s far better feature set/better design (lessons learned from Java/JVM's mistakes were able to be fixed in C#/.NET)



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

Search: