Comment by pron | Hacker News Reader

Comment by pron | Hacker News Reader

Parent Full thread

> 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.

> 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).

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.

Reply on news.ycombinator.com