Hacker News Reader

Comment by pipeline_peak | Hacker News Reader

I love watching C# slowly grow from a boring MS Java clone into something elegant but still useful

Ever since LINQ, maybe even before that, I feel Java is a more boring C# clone. C# keeps innovating their language (borrowing a lot of times from other languages, of course), and then java seems to look and wait and do a half-assed implementation of a lot of tried-and-true C# language features some years later.

Java had two tech advantages over C#: It officially ran on platforms other than Windows and ran well, and their JVM was far ahead of the MS CLR.

Both of these things went away/are going away.

What really remains is Java's reputation over "Embrace, Extend, Extinguish Microsoft" (tho Oracle has been busy trying to destroy Java's reputation ever since they bought Sun) and the larger eco-system/community/existing code bases and sunk costs.

JVM's garbage collectors are at least a decade worth of effort ahead of CLR. I am talking out of my ass here, but from reading people working on large projects JVM has no problem chewing through multi-terabyte large heaps. The recently introduced collectors (Shenandoah and ZGC) even keep the same pause times (something like 99 percentile within 1 ms and 99.9 within 10 ms). The largest heap you might be able to use under CLR without ridiculous GC pauses and overhead is around 200 GB. Yes, value types and Span<T>/whatever lower the GC pressure, but not by a factor of 10×, and value types are coming soon™ anyway.

That's all of no use to me (I don't work on projects like that), but let's not just shove that aside.

I also don't really agree with this:

  > look and wait and do a half-assed implementation of a lot of tried-and-true C# language features some years later

Loom looks like a much more interesting approach compared to async/await hell (I've done it enough to know). I like records and upcoming "withers" much more than { get; set; } (which is easy to write but promotes shit code) because of their focus on immutability. (Yes, I am aware of { get; } and recently introduced { get; init; }, it doesn't really help with the thing withers are trying to solve — copying most fields while replacing one or two values, keeping both the old and the new value immutable). LINQ? maybe, I miss expression trees in Java.

You know C# has records too right? "With" and all.

That should be enough to know he/she hasn't done "enough" to know anything.

Had Oracle not bought Sun, Java would have died in version 6, and MaximeVM would never had become GraalVM.

There weren't other buyers in town, besides IBM, which I probably would have managed it just as Oracle has, given that the trio have been around in Java world since the early days.

Maybe, maybe not. Google was already heavily invested in java with Android. And lots of other places were too. If Oracle hadn't bought it, Google or one of the others might have bought java specifically from Sun. Or may have just let java die and be reborn as an "open source foundation" as they are en vogue now (which to some degree happened anyway, with the proliferation of the OpenJDK).

OpenJDK is developed 90% by Oracle employees, others just take it from there, there is no proliferation .

I think it's been elegant for a number of years now. Pretty much ever since Linq became usable.

Yeah, lambdas and reflection really.

Personally I think reflection is the devil and the reason why we can’t abandon VMs for native compilers.

Reflection does away the need to manually implement serializers. In a growing codebase where data models transform and references to those models begin to rot, that is incredibly useful.

That can be done with code generation at compile time. We don’t need to reflect at runtime for that.

Usability is worse, IMO.

Serialization libraries need to be decoupled from the records being serialized. These two things are compiled into different assemblies, and often written by different people.

Still possible to replace with compile time codegen, but the implementation gonna be complicated and fragile.

Type inference with `var` as well; which was necessary for LINQ anyway IIRC.

Why is it useful for LINQ? I feel like it’s mostly dependent on lambdas and generics.

There are anonymous types for intermediate results in the linq stream. And since they are anonymous types you need the c var keyword when working with the outcome.

….All these years and I’ve never known about Anonymous types. I know about records and dynamic objects. I’m guessing they aren’t used often because I have yet to find them.

LINQ GroupBy() is the most common use I can think of. I would definitely look into that as it's a nice tool to have. Otherwise, keep them in mind if you're ever pulling data from an external source (SQL, JSON, GQL, Redis, etc) and you're annoyed about having to make a class for some trivial operation.

If a library doesn't have an API for using them with generics, you can paper over that with:

    T fn<T>(T throwAway) => Library.Deserialize<T>();

Another example of Anonymous types would be a simple .Select(x=> new {x.ID, x.Name});

Sometimes people lump these in with dynamic objects but those are a very different class of thing indeed.

Now, what would be -really- nice is if we had a way to specify that an anonymous type implements an interface. That could potentially simplify a -lot- of DTO modeling.

Reply on news.ycombinator.com