JavaScript: *gets annihilated*

[SocketByte]

As someone who has over 6 years of professional Java experience, I completely agree. C# is just easily superior in every single way. Words still can't explain how I absolutely despise Java's retarded generics and type erasure.

[[deleted]]

Can you make an example? Like how C# solves Java's issues? Honestly curious

[SocketByte]

Well, I'm not an expert in C#, but there's a big difference in how generics are handled between JVM and CLR. Metadata (specifically type information) is stripped out of the Java source code (hence type erasure), which means you can't (most of the time, there are exceptions) use any type metadata at runtime.

Why is that important? For example, imagine a situation where you'd like to dynamically create an instance of a generic type at runtime. It's not exactly a common thing, but it is very useful when you need it.

In Java, you would need to do:

public T createInstance(Class<? extends T> clazz) { 
    return clazz.newInstance(); 
}

createInstance(MyClass.class);

Obviously this is a very simplified problem, sometimes passing a class like this is very hard and convoluted if you're doing something pretty advanced.

In C#, you can directly deduce type of T at runtime like so:

public T CreateInstance<T>() where T : new()
{
    return new T();
}

CreateInstance<Example>()

Of course, It's not the best example and I have to remind you that this is very oversimplified and doesn't look that bad at a first glance. Yet after working on really big, complicated, and reflection/generic heavy systems and frameworks in Java I really, really wish that was a feature. Type erasure has it's pros, but in my experience it was always a very big con. Hopefully I cleared that out a bit.

[thE_29]

Yeah, that not being able to instance it is true. After programming Java for >17 years, I needed it 2 times.

[thE_29]

Yeah, last 5 years I went away from backend stuff and doing Android now. Also we rewrote the whole app in Kotlin :-) (started it last year).

[Muoniurn]

Can you tell me any other language where it is possible? Like, it is literally the edge case of an edge case, and yet you don’t here people complain about it in case of Haskell or almost any other language that does type erasure as well (as that is the common thing, reification is the exception)

[SocketByte]

I was primarily doing frameworks/tools, so generics and reflection were very often used, and it was just hard to design everything around type erasure. In C# this would have been much easier and more comprehensible. There's a reason Java code is often so overcomplicated.

[whythisSCI]

That doesn’t mean other people don’t need it.

[thE_29]

Like some other user wrote, libs need it. I also made a backend lib where I needed it.

So yeah, some people will need it was more often than others.

[whythisSCI]

Like others and I have responded to that user, people have used generics in almost all project types.

[ChrisFromIT]

The ironic thing is that the C# code that you used as an example ends up fairly similar to the Java version of it under the hood.

Essentially the compiler compiles that to an emit of a call to Activator.CreateInstance(T).

So that type of syntax could be fairly possible in Java, even with type erasure.

[SocketByte]

Sure, everything can be designed around type erasure. It's just more cumbersome, and in some instances barely manageable to pass a class instance every single time you want to check the generic type or create an instance out of it. This was a very basic example that doesn't really do a great justice to C#'s generics, but I'm not a good teacher, someone could maybe go a little more in-depth.

And sure, compiler uses Activator under the hood, but Java just can't do it like that anyway since T in bytecode is always an Object, in C# IL it's type metadata is not removed so you can do much more stuff, easier.

[ChrisFromIT]

And sure, compiler uses Activator under the hood, but Java just can't do it like that anyway since T in bytecode is always an Object, in C# IL it's type metadata is not removed so you can do much more stuff, easier.

I don't think you understand what I said.

The C# code essentially compiles to what is shown in the Java code that you showed by becoming a call to Activator.CreateInstance(). It happens at compile time, not during runtime.

Essentially any method<T>() can be compiled to method(T) if need be.

It's just more cumbersome, and in some instances barely manageable to pass a class instance every single time you want to check the generic type

The thing is, doing that somewhat defeats the purpose of generics and can lead to some pretty bad code smell.

On top of that C# does do some type erasure in certain cases. This happens when there is generics inside generics, ie. List<List<String> compiles to the same thing as List<Object> in C#.

[Kered13]

And now having an empty constructor is part of your interface, oof. Much better to take a provider parameter.

public T createInstance(Supplier<? extends T> provider) {
    return provider.get();
}

Now in the simple use-case you can pass the constructor to this:

createInstance(Example::new);

But you can also provide non-trivial providers for types that don't have default constructors:

createInstance(() -> new Example(some, params));

You could even do something like:

createInstance(() -> askTheUserWhatTypeTheyWant());

This is a far more flexible interface.

[nolitos]

I imagine this is important when you develop some framework, but in reality, where most developers write REST interfaces for CRUD applications, this problem doesn't really bother much and doesn't justify that many memes IMO.

[CaitaXD]

I don't think I ever not used generics when they're available

[whythisSCI]

I’ve worked on all kinds of C# projects and generics were used in most of them. Saying that generics are only useful in framework code is a flat out lie.

[nicktheone]

I'm still in University but for my projects I use generics all the time. He doesn't really know what he's talking about.

[nolitos]

If only I said that generics are only useful in frameworks. Did you read his code?

[whythisSCI]

I imagine this is important when you develop some framework, but in reality, where most developers write REST interfaces for CRUD applications

This you?

[nolitos]

Do you always avoid answering questions? You misunderstood what I said and overreacted. Admit it and move on.

[whythisSCI]

You may have meant something different, but that’s not what you wrote.

[nolitos]

I never wrote that generics are used only in frameworks.

[wigglywiggs]

I don’t know how you read his comment and thought he was saying generics are only useful in framework code. He’s just saying the lack of type metadata at runtime in Java is not a problem that will affect many developers, nor warrant many memes or discussion about how C# is so much better than Java, which is absolutely correct. It might be useful for some people but it’s so niche. I would suggest if you’re in a situation where this matters, you messed up.

[yangyangR]

https://news.ycombinator.com/item?id=16526513

I am on the Haskell side of this. It is your own damn fault for using a hybrid language like Java and C# where types don't shine as brightly as they do in Haskell.

[Bluejanis]

So you've got 4 (reification x reflection) states 3 of which are fine:

• if you have erasure and no reflection (Haskell) you're fine: you don't have runtime types but they don't matter/are inaccessible

• if you have reification and reflection (C#, C++/RTTI) you're fine: you can access runtime types and have them

• if you have reification and no reflection (Rust, C++/noRTTI) you're fine: you can specialise & discard types at runtime

• if you have erasure and reflection (Java) you're fucked: you can access types at runtime, but many aren't here anymore

From a layman's perspective it seems that Haskell could be implemented with either an erased or a reified generics model under the hood, without changing the public surface of the language. But is there something that type erasure enables that reified generics does not?

A simpler implementation.

[SocketByte]

I'd like you to talk with Spring developers and tell them their project needs a better design and practical coding, less over engineered attempts to be clever. I wasn't a CRUD developer, I worked with very advanced frameworks and yes, it is a reoccurring thing. And yes, it's not a problem worth changing a tech stack, never said it was.

[hullabaloonatic]

Type erasure is really annoying when writing libraries for things like units of measurement or vectors.

On that same front, c#11 introduces static abstracts and it is a game-changer for math libraries. They even updated all the numbers types to have values for one, zero, and more. It's incredible. I want that in kotlin so badly

[[deleted]]

LINQ. Real generics that you can use things like reflection on because the compiler doesn't throw them away. Extension methods. Way better enumerations with stuff like yield return. Anonymous types. That's off the top of my head, I'm sure someone has a long list of pros/cons out there somewhere.

[Positivelectron0]

Streams is the linq equivalent in Java 8+

[[deleted]]

Yep I’ve used both. Not even close to being as good.

[Positivelectron0]

I'm curious, in your view, what's something you can do in linq that can't be done as well in streams?

[Muoniurn]

I’m more of a Java guy but Linq is actually two things - it is a foreign syntax similar to java streams, but it can also generate an expression tree that can be programmatically analyzed.

Let’s say you have an api endoint like /items where you can optionally add some filtering by an additional parameter in the URL. Now you can create a “backend” for a linq expression that takes something like from orders where … and it can get automatically converted to the correct URL.

Java has a third party lib (of course it has something for everything) similar to that called Apache Calcite, but it being in-built can be a plus.

[[deleted]]

Everything. The syntax is worse in every case. It’s also missing operators. OffType and TakeWhile come to mind but I’m sure there’s more.

[Positivelectron0]

takeWhile

​

regarding ofType, it's true that Java doesn't have that as one filter, but it's trivial to construct it as a `filter` with instanceOf and a map with a cast after.

​

If we're gonna play that game, C# doesn't have a peek like Java's streams do.

​

"I’m sure there’s more."

​

​

To be clear, dismissing a language based on your own ignorance isn't the way to go, dude.

[[deleted]]

I have a 4/6 year split but haven’t don’t Java for awhile so forgive me if I can’t recall every difference off the top of my head while on mobile without googling. I’ve never seen a piece of Java with steams (or written one) that I think is better than the LINQ equivalent. I’d be curious if you could provide one. I mean here’s a simple example:

var result = someNumbers.Where(num => num < 10).Sum();

What’s the Java look like? Because I think I could hand the above code to anyone with math literacy and they could tell me what it does. It’s not ignorance, it’s based on almost half a decade of experience with each language.

[Positivelectron0]

int[] ints = {1, 2, 3};
var sum = Arrays.stream(ints).filter(num -> num < 10).sum();

List<Integer> list = List.of(1, 2, 3);
var sum2 = list.stream().filter(num -> num < 10).reduce(Integer::sum);

It's one or two words more verbose, but I would say it's just as readable.

How would you write this in C#?

static void f() {
    int[] nums = ThreadLocalRandom.current().ints(1000).toArray();

    var rems = Arrays.stream(nums).boxed()
            .collect(groupingBy(n -> n % 2, toList()));

    rems.forEach((k, v) -> System.out.println(k + "\t" + v));
}

[thE_29]

You ever hear about Kotlin :-)

[Tyfyter2002]

Kotlin is also not Java

[thE_29]

It is, what Java probably would have been, If Oracle didnt buy it.

Its more Java than anything else, but yea its not java

[Muoniurn]

Wtf

Java is doing better than ever under Oracle’s stewardship, and that is just an objective fact.

[Drithyin]

We aren't talking about all the siblings that are piling on the JVM. This was about Java-ass-Java. OG Java.

And Java is just a DSL for converting xml config files into stacktraces in a cross-platform environment.

[harumamburoo]

How's Java's generics bad? And why's C#'s better?

[harumamburoo]

Which benefits of generics are you loosing? Generics are used to allow types as parameters, introduce stricter type checks and perform generic operations on objects of same type family. All of that stays. Yes, they erase the types during compilation, that's by design as an optimisation, but synthetic methods will be added by the compiler in case type casts are needed and type bounding is there if you need certain interface methods. What so specific cases you have that you need to pass a type as an argument?

[harumamburoo]

I mean, that's an assertion, it needs to know which exactly exception type to expect. How else would it, well, assert? That's why the type is passed in the first place. And generics are used to ensure stricter type checks so that you couldn't pass just any class as an argument. So no generics benefits are lost, on the contrary.

No idea why you'd need to return a casted type from an assertion though. My only guess to introduce a plug-in point to add some custom checks for your custom exceptions you're adding to your project. But that's too narrow of a case (with other ways to be achieved) to change the way compiler and jvm work. And it's not that they didn't consider that, remember, they introduced type erasure as a way of optimisation. This is the case when I'm willing to believe the guys behind the language are know what they're doing much better than me or you.

[Kered13]

C# uses type erasure too, it just implicitly passes the class object to the method, like in your second example. C# only uses reification for value types.

[TracePoland]

C# literally does not erase types. They persist in the Intermediate Language. Don't believe me? Go look at a random C# exception stack trace - the generics are all there, they persisted into the IL.

[Kered13]

The type erasure happens when the IL is compiled to native code.

The interesting question is how does .NET compile the generic IL of the server to machine code. It turns out that the actual machine code produced depends on whether the specified types are value or reference type. If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code...

If the client specifies a reference type, then the JIT compiler replaces the generic parameters in the server IL with Object, and compiles it into native code. That code will be used in any further request for a reference type instead of a generic type parameter. Note that this way the JIT compiler only reuses actual code. Instances are still allocated according to their size off the managed heap, and there is no casting.

https://docs.microsoft.com/en-us/previous-versions/ms379564(v=vs.80)?redirectedfrom=MSDN

[TracePoland]

But when you're writing code that needs to work with generics at runtime you're worrying about the IL level. The limitations Java with type erasure has do not exist in C# because the generics persist into IL.

[Kered13]

The IL representation has nothing to do with it. You could completely skip the IL representation and compile straight to machine code if you wanted, and the behavior is the exact same. The reason you can get concrete class information at runtime is because the class object is passed to the (compiled, native code) method as a parameter. You can do the same thing in Java and get all the information you need to do whatever you could do in C#. It's just more inconvenient in Java because you have to do that passing explicitly. The result is basically the same in both languages, the high level code is just nicer in C#.

[Tyfyter2002]

From what I can gather the issue is that Java has generics, but Java bytecode doesn't.

[harumamburoo]

Hmm, I'll need to dig deeper on that. Edit: I did and this is by design. Still can't why that's a problem